Using babel compilation and .babelrc in local Meteor packages

[Discordius]

I am working on an Open Source forum platform (Github), and our setup is such that almost all of my code lives in the packages directory, and is spread over a few different folders (I am using the Vulcan framework, which came with this architectural choice).

I would really like to use the Babel optional chaining plugin, but have been unable to get babel compilation to work for any of the code that lives in my /packages directory. I've added a .babelrc file in the top-level, as well as in the /packages folder, and also in the folders of the individual packages, without any success. I've also played around with adding the babel-compiler plugin as a dependency.

I considered asking about this on StackExchange first, but discovered this question, which seems to be basically the same problem I have, and which didn't get an answer, but only a suggestion to ask the question on Github instead, so I figured I would ask it here.

[benjamn]

Putting a .babelrc file in the individual package directories is the right way to do this, along with putting api.use("ecmascript") in the package.js files of those packages. When babel-compiler looks for .babelrc files, it searches the parent directories of the file that's being compiled, but it does not escape from individual package directories. You could probably create .babelrc symlinks to a shared .babelrc file somewhere else, so you could share the contents of the file, but you'd have to create a symlink in every package.

The other question is where to install the Babel plugin packages themselves. I think the best place to do that is in the top-level application node_modules directory (in other words, list them in the devDependencies of your application), though ideally packages installed via Npm.depends should also work.

If the setup I've described doesn't work for some reason, that's a bug that we should fix.

[benjamn]

By the way, the problem described by the question you linked to seems to be related to enabling new syntax in the Babel parser, rather than finding the .babelrc files. If your error message is similar, the solution might be as simple as including the syntax plugin along with the transform plugin.

I'd be happy to take a look at a reproduction, if you have time to put one together.

[Discordius]

Ok, here is a reproduction:

https://github.com/Discordius/MeteorBabelRc

[Discordius]

@benjamn: Did you end up taking a look at the reproduction?

[coagmano]

I just had a look and adding the plugins to the root app didn't seem to do anything.

What did work was adding an Npm.depends block to Package.js

  Npm.depends({
    "@babel/core": "7.4.3",
    "@babel/plugin-proposal-optional-chaining": "7.2.0",
    "@babel/plugin-syntax-optional-chaining": "7.2.0"
  })

This compiles and doesn't ship the babel code to the client, but does mean you need a copy of babel and the plug-ins installed for each package that uses this

[heberallred]

It would be super nice if there was a way to do this without Npm.depends in each Meteor package because this copies the NPM modules into every Meteor package that uses it (within the .npm folder), and takes longer to build (installing the same NPM package many times).

In our project, we tried to make it use a global version of "@babel/plugin-proposal-optional-chaining" within our project (with package.json), but for some reason it won't work. Ideally we would create a meteor package, that when included in another package using api.use, would automatically enable these various Babel NPM plugins, and use api.imply('ecmascript') as well so it's just 1 line of code to enable. We haven't found a way to do it yet.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[coagmano]

Still relevant

[heberallred]

One thing I will say is that the built-in optional chaining for Meteor 1.8.2 is awesome! I think they should promote it more because it's a big deal.

[coagmano]

I didn't even realise it was built in!
I assume it was automatic because of the corresponding babel-env update now that optional chaining is stage 4

I wonder if that also provides backwards-compat with packages that start using it?

[benjamn]

@coagmano Yep, that's the beauty of Meteor compiling package and application code at application build time, using the current/latest version of babel-compiler! In the npm ecosystem, you'd be stuck with whatever the package author decided to publish.

Note, however, that compiler plugins are built at meteor publish time, so packages that provide compiler plugins will need to be republished with Meteor 1.8.2 (with a minor version bump).

Also, since babel-compiler is a core package, and we bumped its minor version in Meteor 1.8.2, the only way to get the latest version of babel-compiler is to use Meteor 1.8.2, so the addition of optional chaining is not automatically enabled for Meteor 1.8.1 (and earlier) apps.

[heberallred]

@benjamn This is pretty awesome. I think the Meteor team should put it a bit more prominently that optional chaining works now in 1.8.2. We were pleasantly surprised when we updated :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[eric-burel]

Hi guys, still relevant, there seems to be a fix with NPM.depends, but then why don't we have an error message when dependencies are missing? I would expect the build to fail or something when the dependencies aren't there.
Also not being able to use JS babel configs is limiting.

Edit: the NPM.depends doesn't really seem to fix it to me and it's not obvious to debug, I have absolutely no debug message and didn't found any option to make Babel build more verbose :/