-
Notifications
You must be signed in to change notification settings - Fork 3
Meteor should transpile js in node_modules #6
Comments
Maybe this can be somehow configurable. There are indeed packages that ship original source files written in ES6 module format (and using new language features). These packages usually also include transpiled "dist" files. One advantage of having this is that if someone wants to make an NPM package just for Meteor, they don't need to worry about setting up Webpack/Babel/etc, they can just write code, publish it, say that it works in Meteor, and forget about it, without having to worry about tooling... because Meteor already has all the tooling. |
Perhaps we could do something similar to what rollup does where you can specify a |
I hit this issue ~50% of the time I install a new module from npm, which forces me to hunt for an alternate version to specifically make Meteor happy. Other projects I'm working on (based on Webpack, React Native, etc.) run these node_modules without a hitch. It's starting to get pretty painful. It seems like a lot of modules, especially those in the
What can we do to fix this? Can Meteor do some additional transpilation on the bundle before sending to the browser? |
@joncursi So those npm packages don't work in any version of Node without transpilation? That seems like a strange choice for them to be making! While I can certainly feel your pain, you're attempting (if I understand your project) to reuse code designed to work specifically with React Native in Meteor projects. I would love to make that easier, if possible, but the rate at which you encounter this problem is definitely not representative of most of the npm ecosystem, nor of most Meteor apps. Just something to bear in mind. |
@ejfrancis The The last time I looked into that, the problem was that other CommonJS modules from npm don't know how to deal with what's exported by the ECMAScript Using the |
But there's also client code and supporting older browsers. It may be possible some NPM module is designed for browsers, but the code published is for too recent of a browser than supported by the app dev. What about some sort of configuration json file that Meteor |
@trusktr That's a good point. I think the only configuration we should need is the |
That would be ideal if package authors were willing to put certain fields in package.json. The reality is: it is unrealistic to expect that every package author will put every required field for every possible target environment into package.json. It would be great for a Meteor app dev to be able to apply a setting without relying on a package dev having to do it, and without having to fork a package just to add the setting. |
I'm comfortable saying that you (an npm package author) have to specify |
@benjamn After reading your technical comments, which are a little beyond me, I hope that my use case, which I detailed in the original issue before turning it into a feature request, is still relevant. Just to sum up, my meteor builds are failing when trying to install quasar-framework (a vue-based ui framework) from npm. If I'm barking up the wrong tree by introducing the problem in this feature request please set me right. |
Hi @mwarren2, I am not sure how just npm installing Anyway, there is a demo Meteor boilerplate from Quasar Framework: If I understand correctly, for now they have just copied their es6 dist file into the Hope this helps. |
@ghybs Thanks. However the Meteor boilerplate at quasar-template-meteor is mine, I've been working for a while with quasar-framework's creator to get it working with Meteor from npm. |
Just an idea: after NPM installing stuff, use a postinstall script to
symlink the needed file(s) into an imports folder. Then it can at least be
automatic that way, for now.
On Jun 25, 2017 11:38 PM, "mwarren2" <[email protected]> wrote:
@ghybs <https://github.com/ghybs> Thanks. However the Meteor boilerplate at
quasar-template-meteor is mine, I've been working for a while with
quasar-framework's creator to get it working with Meteor.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASKzp0R31nHu7z9MLKYB1VJh7iYo0Vzks5sH1H4gaJpZM4Nxxr2>
.
|
I've ran into many issues with NPM packages using ES6 syntax when running the app on older browsers. Any workaround for this? |
@benjamn today I wrote a post on Meteor forums about things related to this topic. I think that Meteor should transpile some of the packages in the In essence, I wouldn't want to wait until 2018 (or even 2020) when ES import/export syntax will be available in Node and all browsers |
To be completely honest, the main reasons we don't currently compile modules in We've always known that this assumption would become less and less reasonable over time, as package authors began to publish newer syntax to npm, and at some point we would have to start compiling code from npm, at least for the browser. Node 8 handles almost everything natively (except for ECMAScript module syntax), but that only helps on the server. Now that Meteor 1.6 is out, I think this issue deserves top priority for Meteor 1.6.1, which is why I put it in the milestone. Even compared to the other feature requests currently in the milestone, I think this feature is by far the most important. At the very least, we have to start compiling any modules that we include in the client bundle. This is complicated for some obscure legacy reasons, but that doesn't matter. We can rewrite the problematic code from scratch, if necessary. Ideally, I would love to reconsider the dialect of ECMAScript that compiler plugins in Meteor (not only Performance remains a concern, but Node 8 is noticeably faster, Babel is getting faster all the time, and of course we can cache the compiled code aggressively. Thanks to everyone for keeping this issue active. I look forward to making progress on this soon, because I agree it's long overdue. |
@benjamn great to hear that! I think it's definitely the right time to do it. I wouldn't be concerned a lot about performance because as you said we can always make use of the cache. The initial load might take more time but later it will be rather not very common to recompile everything. I would only be worried about tree shaking implementation but Rollup does it (or at least it's what they say in documentation). If it goes about compilers, I see that for example, the typescript compiler has an option to customize target ES version per project https://github.com/barbatus/typescript#es6 that way developers can just choose. |
Another use case for this is the react-facebook NPM package which currently contains some ES6 https://github.com/seeden/react-facebook meaning that I can't currently use it on the clientside. |
I am assuming that nothing in Have you already come up with some ideas on what the API will look like for opting into transpiling certain packages in node_modules? |
Would a it make sense to have an option for specifying that transient dependencies of a targeted package should also be transpiled? Manually having to specify various dependency packages of a main package the the app depends on might get tedious, but it would lead to the best performance. In many cases, just specifying for Meteor to transpile a package's whole dependency tree would be easier and perfectly fine if the build time difference is tolerable. |
meteor/meteor#8020 (comment) Best solution will be introduced in 1.6.1: meteor/meteor-feature-requests#6 (comment)
Here is another use-case: Meteor doesn't work so well at the moment with Box, specifically box-ui-elements and box-react-ui. Maybe it's a good idea if it can be controlled what packages in node_modules will be transpiled rather than transpiling everything... PS: I've put in a request to them to include ES5 in their distribution - box/box-ui-elements#184. |
If a package in node_modules needs to be compiled for older browsers, simply symlink the package directory into your application somewhere, and then import the package as you normally would. Because of the symlink, code within the package will be compiled as if it was part of your application, and any imports that refer to modules in the package will automatically use the compiled code rather than the raw code from node_modules. Note that you can also symlink individual files to make them be compiled like application modules, rather than linking an entire package directory. Creating symlinks could be considered a form of configuration, but otherwise this is a zero-configuration solution to selectively compiling packages within node_modules, which has been something of a holy grail in the JavaScript community lately. meteor/meteor-feature-requests#6
If a package in node_modules needs to be compiled for older browsers, simply symlink the package directory into your application somewhere, and then import the package as you normally would. Because of the symlink, code within the package will be compiled as if it was part of your application, and any imports that refer to modules in the package will automatically use the compiled code rather than the raw code from node_modules. Note that you can also symlink individual files to make them be compiled like application modules, rather than linking an entire package directory. Creating symlinks could be considered a form of configuration, but otherwise this is a zero-configuration solution to selectively compiling packages within node_modules, which has been something of a holy grail in the JavaScript community lately. meteor/meteor-feature-requests#6
If a package in node_modules needs to be compiled for older browsers, simply symlink the package directory into your application somewhere, and then import the package as you normally would. Because of the symlink, code within the package will be compiled as if it was part of your application, and any imports that refer to modules in the package will automatically use the compiled code rather than the raw code from node_modules. Note that you can also symlink individual files to make them be compiled like application modules, rather than linking an entire package directory. Creating symlinks could be considered a form of configuration, but otherwise this is a zero-configuration solution to selectively compiling packages within node_modules, which has been something of a holy grail in the JavaScript community lately. meteor/meteor-feature-requests#6
We think we've finally found a way to solve this problem: meteor/meteor#9771 tl;dr Use symbolic links to expose |
That feature looks sweet! Can we make it even easier? For example - a set of config options in {
"meteor": {
"mainModule": {
"client": "client/main.js",
"server": "server/main.js"
},
"modernModules": {
"package-name": {
"main": "src/main.js"
}
}
}
} Basically, that setting could create the symlinks from config at compile time, instead of requiring the user to set those up (may be easier especially on Windows). |
@CaptainN Honestly I think the main use case will be cloning the package repository locally and then running I would rather not invent new configuration options that are less powerful than the "real" way of doing this, which may involve modifying the package locally, adding your own That said, if folks really need the new functionality to be simpler, we can maybe consider implementing another form of configuration in the future. |
@benjamn That's true. It's actually similar to how I manage certain Meteor packages. I wonder whether there are enough packages in npm that could benefit from simply using the ES6+ modules directly (and getting the benefits of Meteor's modern/legacy builds) rather than always using what are essentially legacy builds in the main prop/dist folders of many npm packages. You are probably right though - it may not be as simple in most cases as defining the entry point in an existing npm module, which is the extent of flexibility I was thinking about with regard to configuration (basically, an alternative to symlinks, with one additional config option). |
@benjamn My original reason for opening this issue was due to problems with quasar-framework, which I had to transpile manually, and this has now been solved. meteor/meteor#9771 has elegantly dealt with the problem, which I solved by linking to the node_modules installation from the /imports folder, and employing Thank you for all your work on this. As far as I am concerned this issue can be closed. |
@mwarren2 That's great to hear! Feel free to comment here in the future if you run into any problems with this workflow. |
I have run into this problem with a few npm packages lately, big packages like TypeORM and BabylonJS, etc. With JS features growing, and the general acceptance of I would love to have an option to manually specify which npm module should be included in the build process. I don't know, something like {
"build": {
"includeModules": [
"typeorm",
[ "@babylonjs/core", { "target": [ "browser" ] } ]
]
}
} Some packages, such as As I have other projects using |
Migrated from: meteor/meteor#8640
The text was updated successfully, but these errors were encountered: