-
Notifications
You must be signed in to change notification settings - Fork 36
NPM Meeting Feedback
I recently gave a demo of our plans to support modular NPM development as realized within the Patterns for Modular ES6 Development project. The following conundrums were received in the feedback:
Why do all components need to be external to the app, when the norm will be for them to be developed along with the app?
We can easilly add support for internal components too.
How will we migrate code one package at a time, even though all of our libraries share the same root require-path (e.g. br & caplin)?
Since we can't expect to get package names like presenter on NPM, we'll make use of NPM scopes to instead create packages with names like @brjs/presenter.
As packages are migrated to NPM they will need to use the correct names for any NPM packages they depend on, so require('@brjs/presenter/modules/PresentationModel') instead of require('br/presenter/PresentationModel'). However, existing BRJS libraries can continue to use the original name due to the availability of require-path mapping rules (e.g. br/presenter -> @brjs/presenter).
Yes, since the NPM patterns require us to put source code into a source directory (e.g. src or modules) yet our existing require-paths require the code to live immediately beneath the root of the package once converted to NPM. Again, we can fix using mapping rules, for example:
-
br/presenter->@brjs/presenter -
br/presenter/->@brjs/presenter/modules/
For many libraries this means that requiring the entire package (e.g. @brjs/presenter) will actually cause an error since we won't define main within package.json, and we won't have created an index.js either.
How will we deal with the fact that a developer requiring a single file from the grid module won't want to have to deploy the entire package.
Although NPM downloads packages atomically, Node.js allows you to require modules within a package using standard require-paths. Provided the bundling-tool understands this (e.g. 'browserify' or 'SystemJS Builder'), then only the modules a developer uses should be bundled.
A programmatic service-registry (called @brjs/service-registry) will be made available within NPM that allows developers to register service-factories and require services (as per this comment). NPM developers will be responsible for registering all of the service-factories needed to bootstrap their app, workbench or test.
BRJS developers will use the same service registry, but where the service-factories are automatically registered based on the configured aliases. The br/ServiceRegistry & caplin/core/ServiceRegistry modules will become simple proxies to @brjs/service-registry.
The event-hub (br/EventHub) will be made available as @brjs/eventhub, and the IoC mechanism becomes require('@brjs/service-registry').get(), since the calling code can't know what has been registered.
For the time being we won't be able to, but SystemJS NPM support is on Guy Bedford's radar:
Currently CSS bundling is only supported in jspm, please post an issue if you would like support outside of jspm.
So it's possible that it might be fixed for us, or I might create a 'systemjsify' library that makes SystemJS usable without any remnants of JSPM whatsoever.