We'd like to be able to add custom functionality to polymer build and polymer serve by configuring custom babel plugins.
For example, since polymer-cli uses babel internally, we would add a babel.config.js file to our workspace/project-root, e.g.:
module.exports = function (api) {
api.cache(true);
const presets = [ ];
const plugins = [
"#babel/plugin-proposal-optional-chaining"
];
return {
presets,
plugins
};
}
...and then we could serve or build our project with support for optional-chaining, etc This would allow us to do all sorts of things by writing additional babel plugins to handle stuff like minification inside template HTML strings...
Unfortunately, this doesn't currently work. polymer-build seems to load the configuration (due to its use of babel/core?), but polymer-analyze doesn't. An error is generated in the build-optimization step performed by polymer-analyze as soon as it encounters optional-chaining syntax in our source:
error: Error: Unable to get document file:///.../somefile.js: This experimental syntax requires enabling the parser plugin:
'optionalChaining' (423:6)
at BuildAnalyzer.<anonymous> (/usr/local/share/.config/yarn/global/node_modules/polymer-build/lib/analyzer.js:342:23)
at Generator.next (<anonymous>)
at fulfilled (/usr/local/share/.config/yarn/global/node_modules/polymer-build/lib/analyzer.js:17:58)
at process._tickCallback (internal/process/next_tick.js:68:7)
polymer serve also generates an error:
Error { SyntaxError: This experimental syntax requires enabling the parser plugin: 'optionalChaining' (423:6)
at Parser.raise (/usr/local/share/.config/yarn/global/node_modules/babylon/lib/index.js:776:15)
at Parser.expectPlugin (/usr/local/share/.config/yarn/global/node_modules/babylon/lib/index.js:2084:18)
...
pos: 13056, loc: Position { line: 423, column: 6 },
missingPlugin: [ 'optionalChaining' ] }
In both cases, I've confirmed that the babel.config.js file is being loaded. But babel is included by several different packages used in polymer-cli, so my suspicion is that in some of them, babel is being used without (babel/core having loaded) configuration info.
Can anyone involved with the polymer project confirm whether I'm correct in identifying the main issue? I'm looking into the possibility of contributing a fix/enhancement if the scope isn't too large.
Thanks.
I think for this you need to write your own custom build. Polymer-cli will provide its tool also for this. Have a look at this example:
https://github.com/PolymerElements/generator-polymer-init-custom-build
For us, this issue was preventing us from using modern JS language features (like optional chaining and the nullish coalescing operator) which have wide support in modern browsers.
The only solution we could come up with was forking the Polymer tools monorepo and adding in support for the appropriate Babel plugins ourselves.
The file in question is /packages/build/src/js-transform.ts. Both serve and build use this file for Babel transforms. We switched to using Rollup for our build process, but we still needed a development server and couldn't get any others to work, so we forked the repo and built our own version of the standalone polyserve package. Would love to some day switch to Modern Web's #web/dev-server.
Related
I'm converting a project that was built using Create React App to use ParcelJS as a bundler instead. Strangely, a dependency that I imported during development (#twilio/voice-sdk) works fine in the CRA version of the application, but I get the following error when I try to invoke the constructor in the Parcel version:
TypeError: (this._options.AudioHelper || audiohelper_1.default) is not a constructor
The package is identical between both (#v2.1.1, the latest). I'm importing using ESM syntax, so:
import { Device } from '#twilio/voice-sdk'
I trying using CommonJS syntax (require) and it still didn't work. I've dug into the compiled code, and that seems to be the issue. I imagine there are a lot of differences, but one that I've noticed is here:
On the left is the code compiled by Create React App, which does seem to be exporting something more substantial than on the left - is the export just an empty object? If so, it's no wonder I'm getting a constructor error.
Unfortunately, no amount of googling and SO sleuthing has clarified what I could do to make ParcelJS transpile this dependency properly, if that's the issue. I've tried to make the babel config for ParcelJS match CRA more closely by adding the following to a babel.config.json
{
"plugins": [
"#babel/plugin-transform-modules-commonjs"
]
}
But no luck. Any ideas from where to go from here, or is it time to switch to Webpack?
It looks like Twilio package has a problem when using Parcel 2: https://github.com/twilio/twilio-voice.js/issues/101
I seem to absolutely not grasp where to put root programmatic options for the babel.
If I have a monorepo and need to tell the different sub packages that they shall look upwards for my babel.config.js then I should put rootMode: "upwards" into the .babelrc of the sub packages, correct? This does not work, because of the resulting error
Error: .rootMode is only allowed in root programmatic options
Somehow I simply can't find any example of where to put/use root programmatic options... Can anyone point me to the right direction?
If you are using Webpack, you need to put it there.
module: {
[..]
rules: [
// Transpile ES6 Javascript into ES5 with babel loader
{
test: /\.jsx?$/,
exclude: [/node_modules/, /json/],
loader: 'babel-loader',
options: {
rootMode: 'upward'
},
},
[..]
],
[..]
},
Otherwise I had the same issue than you, I can't put it in the package.json file using the key babel.
Any API-related options are called programmatic options. Take a look at my discussion with the primary maintainer of Babel: https://github.com/babel/babel/discussions/14405.
It's when you specify them directly to Babel (babel.transformSync(code, programmaticOptions) or to the Babel integration you are using (e.g. babel-loader, which can pass them to its internal babel.transform call). In other words, not in presets or config files. [...]
by #nicolo-ribaudo - Babel core team.
I got this error using my (probably non-standard) monorepo setup where I have top-level subdirectories for each of my packages. No top-level package. When I upgraded to Babel 7, my Jest tests were no longer transforming packages that were yarn linked into the package where I was running Jest.
I added a top-level babel.config.js as part of Babel's monorepo instructions. I had rootMode: "upwards" in these three places:
ui-package/webpack.config.js for transforming the app.
ui-package/babel-jest.js for the tests, where it appeared like:
module.exports = require("babel-jest").createTransformer({
rootMode: "upward",
})
and was referenced from jest.config.js in that same dir like:
transform: {
"^.+\\.jsx?$": "./babel-jest.js",
},
And in /babel.config.js, the newly added top-level babel conf file.
Removing it from the last one removed the error.
I have built a custom element/web component to load and display Unity generated WebGL content. The web component imports the UnityLoader.js module - and works fine when used within an app served with 'polymer serve'.
However, when I build an app that uses my web component via the Polymer-CLI build process, no errors are given, but when I access a page using my component I always end up with an error from within UnityLoader.js:
"ReferenceError: BabelHelpers is not defined"
If I create the element directly within my app (in other words it is no longer managed by bower) then I can exclude the minification and compilation steps within the build section of my application's polymer.json file and the built version of the app works fine.
"builds": [
{
"preset": "es5-bundled",
"js": {
"compile": {"exclude": ["content/**/*","UnityLoader.js"]},
"minify": {"exclude": ["content/**/*","UnityLoader.js"]}
},
"html": {
"minify": {"exclude": ["content/**/*"]}
}
}
]
I've looked at my application's polymer.json file and I can see that the extraDependecies node contains some dependencies that other web components have placed there:
"extraDependencies": [
"bower_components/webcomponentsjs/*.js",
"!bower_components/webcomponentsjs/gulpfile.js",
"manifest.json",
"bower_components/plastic-image/intersection-observer.js",
"bower_components/ua-parser-js/dist/ua-parser.min.js"
],
I have UnityLoader.js within the extraDependencies of the element's polymer.json but that isn't getting cascaded up to an application that imports/consumes the element - which I guess must be possible as plastic-image and ua-parser-js have done it (I've looked at their bower_components folders and nothing seems obvious - other than the latter is installed as a dependency of the former).
Any ideas on how I can make sure that the UnityLoader.js that my web component uses is not compiled or minified during the build process of an application that consumes it?
I was having a similar issue with firebase-auth.js when making an ES5 build using polymer-cli 1.7.0. There might be a problem when compiling/minifying specific files. I had to roll back to 1.6.0 using npm install -g polymer-cli#1.6.0 to fix the problem.
I'm getting this error:
Unknown plugin "transform-class-properties" specified in "base" at 0, attempted to resolve relative to "/home/me/Projects/myproj/src"
The message is pretty clear, so I know why it's happening, but I want to change where Babel looks for the plugins/presets/packages.
I'm using Babel with rollup via rollup-plugin-babel.
The options I'm giving it are:
{ plugins: [ 'transform-class-properties', 'transform-object-rest-spread' ],
babelrc: false }
However, I can't find an option to change where Babel looks for the plugins. Is there no way to do this without rewriting my plugins list to use absolute paths?
I also can't find a public API method for extracting the dependencies from .babelrc, so it's pretty hard to manually rewrite the file to use full paths. N.B. Babel configs might also be stored in package.json, and there's been some talk about adding support for .babelrc.js too -- I really don't want to maintain my own project that searches for all the different places a babel config might be hiding, parse the file(s), and scan it for all the plugins, with and without the arbitrary babel-plugin- prefixes.
You can use NODE_PATH to do the same.
$ npx babel test.js
Unknown plugin "external-helpers" specified in "/Users/tarun.lalwani/Desktop/babeltest/.babelrc" at 0, attempted to resolve relative to "/Users/tarun.lalwani/Desktop/babeltest"
After specifying the path for modules in a different location
$ NODE_PATH=/Users/tarun.lalwani/Desktop/babeltest2/node_modules npx babel test.js
function test() {
this.abc = function (url) {
return console.log(url);
};
}
NODE_PATH environment variable allows you to specify additional locations where the modules can be searched for
I have a project that uses "coffee-script": "^1.7.1" in its package.json.
The code has this line in it:
[{id: id, name: name}, ...] = result.rows
This compiles fine using coffeescript version 1.7.1
The problem is that I am trying to use mocha for unit tests and it gives me an error on this line:
Parse error on line xyz: Unexpected '...'
Apparently mocha uses an older coffeescript. Is there a way to make it work without adjusting the source for mocha?
EDIT:
my Gruntfile.coffee:
'use strict'
module.exports = ->
#initConfig
cafemocha:
src: ['test/*.coffee']
options:
reporter: 'spec'
ui: 'bdd'
coffee:
compile:
files:
'lib/mylib.js': ['src/*.coffee']
#loadNpmTasks 'grunt-cafe-mocha'
#loadNpmTasks 'grunt-contrib-coffee'
#registerTask 'default', ['coffee', 'cafemocha']
I added mocha.opts to the test directory:
--require coffee-script/register
--compilers coffee:coffee-script/register
--reporter spec
--ui bdd
but, still, when I run grunt, it gives me the same error. I am new to this environment, and I find it too complicated, please help.
Starting from version 1.7.x CoffeeScript compiler should be explicitly registered (see change log for version 1.7.0).
So, the problem is that CoffeeScript compiler is not registered when you're running your mocha tests, so node.js treats all your .coffee files as .js files.
The best possible solution is to specify --compilers option for your mocha tests:
--compilers coffee:coffee-script/register
If you don't want to include it to every mocha call, you could set it up using mocha.opts file.
Here are some useful links:
issue about it on github
reference in mocha docs
the reason behind this breaking change in CoffeeScript engine
Update
Looks like your issue is much deeper then I thought.
First, grunt-cafe-mocha doesn't respect mocha.opts because it's running tests by requireing mocha as a dependency, instead of calling mocha test runner.
So, it would've been enough to add require('coffee-script/register') to the top of your gruntfile, if not for this old grunt issue.
In short, grunt uses coffee-script 1.3.x, forcing all its tasks to use the same version of coffee. I had the same problem with grunt-contrib-connect, being unable to use latest coffee-script in my express app.
So, the only help I can offer you is a small grunt task I wrote to solve similar problem in one of my projects. It runs mocha in a separate child process, thus completely isolating it from grunt.
N.B. I had a thought about releasing this task to npm, but considered it too minor.