meteor-feature-requests
meteor-feature-requests copied to clipboard
Atmosphere to NPM migration through extensions to package.json
I'd like to see a way to migrate to NPM, while retaining most of the features we have in atmosphere packages. This could be done in a similar way as other source based distributions do it, by extending the package.json with hooks for Meteor end points - either precompiled, or to be compiled and cached at install time.
- Server and Client
- web clients - modern, legacy, cordova, (and extensible; react native, nativescript, service workers, etc.)
- Non-code assets - CSS/SCSS, images, etc.
- atmosphere deps in the short term, during transition
- Lazy loading by default, eager loading by configuration
- build plugins api
- anything I missed
If we had a JSON setting in package.json that mapped to the meteor package API, it seems we could get this working by doing a translation internally (automating the creating of compatible package.js files - and compiling the source).
It'd also be nice if we could distribute as source. I know there can be performance issues with that (and probably some other concerns off which I'm not aware), but maybe we can solve it by compiling at install time (or first run), instead of at build time. This would solve a few problems:
- Stale repos can't become stale any more - they'll always get the benefits of the latest transforms.
- Standardizes (and centralizes) polyfills/runtime/core-js across packages, instead of getting remnants of different versions
- TypeScript and Svelte projects already benefit from source availability (though Typescript projects do often ship with dts files). This is actually necessary for Svelte packages.
- Precompiled assets are increasingly facing compatibility problems with different versions of the transpiler results and support libraries being bundled in to distribution packages. Even Meteor is seeing this in some not often updated packages. This is true even of vanilla js transpiled through babel and core-js (and conflicting runtime/polyfill versions). Maybe it's better to solve this early instead of waiting for it to become a larger problem?