-
-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract babel config into .babelrc file and add it to .npmignore #32
Comments
I'm not sure I can follow: You import the source of portal-vue in your app and then get this error? I don't see how that could be happening because of anything in portal-vue - if you import a file form an npm package, it will be treated by webpack according to your proejct's config. Can you demonstrate this in a small repo or something?
Oh, that indeed seems like a small slipup on my part. Will fix this as quickly as I can. Strange that this didn'T produce any errors for me...
Probably best to switch to something like babel-preset-env, or babel-preset-latest ... |
I wouldn't think it would either... but here we are :p Here is a repo of the issue: https://github.com/nelsonlaquet/portal-vue-bug-repo
Likely because your node_modules still had an installation of the stage-2 package in it from when it was in the package.json before. Node module resolution only cares what's on the filesystem, not your dependencies listed in package.json. |
I totally forgot to mention that by going into node_modules/portal-vue/package.json and removing the "babel" entry makes it compile just fine without having the presets installed. So I know that it's specifically caused by the configuration. |
You mean the whole Babel config? That's still weird, but a start to figure this out... Thanks. |
No, just the parts that include the stage-2 and es2015 plugins. Sorry, I should have been more specific. |
Okay so I loked into this. The stage-2/stage-3 thing is of course a wrong config on my part. The fact that is uses the local bable-config is a feature of babel, and it makes sense, thinking about it. |
@LinusBorg The "es2015" preset error remains an issue when building an application using Webpack, especially now that all the "es----" presets are deprecated and Babel encourages use of the "env" preset. See also:
from the relevant issue with Babel: babel/babel#6766 It seems you'd be able to solve this easily by moving your babel settings into a |
Certainly doable. Yet as a side question, why would you compile portal-vue, if it already exports compiled bundle files? |
I'm not; I'm carpet-excluding the contents of But Babel seems to still process the nested configuration. |
That should definitely not happen, you should doublecheck your config. excluding node_modules from babel-loader will make babel blind to anything in that folder. |
Sidenote: With babel 7, this should no longer be an issue as long as your project uses a I'll solve this nonetheless with the migration to a vue-cli 3 based setup soon (#156). |
Note: This will be no longer an issue in 2.0.0 which will use babel 7 and |
Done in the 1.5.0 (or 1.5.1?) release (currently |
If you do not have the es2015 and stage-2 preset packages installed in your application, compilation fails when building a WebPack bundle of an application that depends on portal-vue with the following error:
Compilation works when the es2015/stage-2 presets are both installed. It seems this is due to the "babel" options in this package's package.json file overriding/merging into my own babel configuration and importing these plugins/presets.
Interestingly, the "devDependencies" of portal-vue includes the stage-3 preset, but the babel options only import in stage-2. I'm wondering if this will cause an issue for anyone who pulls down this repo to do development on portal-vue.
Seeing as it appears that the dist/*.js files have already been processed by babel, is there any way to have these options only be applied during the development and packaging of portal-vue itself, and not in the development and packaging of applications that use it?
The es2015 preset isn't always necessary; and generally having a dependency on a stage-x isn't suitable for production (as features will move between stage-x presets as they mature). So I'd prefer to not be required to pull them down.
Otherwise, awesome package!
The text was updated successfully, but these errors were encountered: