Permalink
Browse files

add error for decorators not being implemented yet

  • Loading branch information...
kittens committed Nov 12, 2015
1 parent 2d3760c commit 69fb1854d79e25f63e0b7553ba966716397eb382
@@ -70,12 +70,18 @@ export default function ({ types: t }) {
return false;
}
function doError(path) {
throw path.buildCodeFrameError("Decorators are not supported yet in 6.x pending proposal update.");
}
return {
inherits: require("babel-plugin-syntax-decorators"),
visitor: {
ClassExpression(path) {
if (!hasDecorators(path)) return;
doError(path);
explodeClass(path);
let ref = path.scope.generateDeclaredUidIdentifier("ref");
@@ -92,6 +98,7 @@ export default function ({ types: t }) {
ClassDeclaration(path) {
if (!hasDecorators(path)) return;
doError(path);
explodeClass(path);
let ref = path.node.id;
@@ -105,6 +112,7 @@ export default function ({ types: t }) {
ObjectExpression(path) {
if (!hasDecorators(path)) return;
doError(path);
}
}
};

This file was deleted.

Oops, something went wrong.

This file was deleted.

Oops, something went wrong.

This file was deleted.

Oops, something went wrong.

This file was deleted.

Oops, something went wrong.

This file was deleted.

Oops, something went wrong.

This file was deleted.

Oops, something went wrong.

This file was deleted.

Oops, something went wrong.

This file was deleted.

Oops, something went wrong.

This file was deleted.

Oops, something went wrong.

13 comments on commit 69fb185

@elierotenberg

This comment has been minimized.

elierotenberg replied Nov 20, 2015

Hi @sebmck,
Does Babel plan to re-implement this feature any time soon in Babel 6? Is there any way I can contribute to this?

Thanks,

@loganfsmyth

This comment has been minimized.

Member

loganfsmyth replied Nov 20, 2015

@elierotenberg As the issue says

Decorators are not supported yet in 6.x pending proposal update.

it's not specifically blocked on Babel, there is just some uncertainty around the official proposed spec at the moment. Implementing it when the official behavior is unknown wouldn't be ideal.

@elierotenberg

This comment has been minimized.

elierotenberg replied Nov 20, 2015

Ok, thanks @loganfsmyth :)
I can only blame myself since decorators support has always been explicitly flagged as experimental in Babel, but currently its preventing me from migrating to Babel 6. Having at least a "legacy semantics" (= identical to pre-v6) implementation until the proposal is updated/clarified would be really nice.

@kmalakoff

This comment has been minimized.

kmalakoff replied Nov 21, 2015

👍 a warning instead of removing the functionality in the short term would be preferable.

Alternatively, someone could split this out into an experimental babel decorator plugin package on npm (eg. babel-plugin-transform-decorators-experimental) to provide a solution to those of us using the experimental feature until the proposal has been updated.

I'm waiting for 6.2.2 to be released to fix a bug blocking my migration to babel 6, but if no one (hint to @elierotenberg) has split this out by then, I can do it.

@loganfsmyth

This comment has been minimized.

Member

loganfsmyth replied Nov 21, 2015

@kmalakoff

This comment has been minimized.

kmalakoff replied Nov 22, 2015

Thanks for pointing that out! I was tracking the wrong package.

Do you think the presets can be updated too? It looks like they are still at 6.1.18 https://github.com/babel/babel/blob/master/packages/babel-preset-es2015/package.json. I'm not sure if there is an easy was to keep them in sync with their dependent plugins?

@loganfsmyth

This comment has been minimized.

Member

loganfsmyth replied Nov 22, 2015

The presets track a range. ^6.1.18 means >=6.1.18 < 7.0.0, which includes 6.2.2. If you uninstall and reinstall, you'll get it.

@kmalakoff

This comment has been minimized.

kmalakoff replied Nov 22, 2015

I use david to check for outdated dependencies and it looks like it doesn't work with nested dependencies inside the presets. Not sure if there is a good way with the new babel plugin architecture to check for dependency changes in presets. Maybe it is fine in npm3 with flat dependencies, but I haven't moved over due to the poor performance. Is outdated dependency checking working in the presets? (npm outdated bails on git repos so I can't use it).

Quick follow up...I'm trying to get the decorators to work and am running into the following error:

Property right of AssignmentExpression expected node to be of a type ["Expression"] but instead got "Decorator"

I was wondering, what is your workflow for debugging plugin tests? I would like to have the code auto-compiled (watch) and step through the tests in a debugger. This is a great opportunity to learn more about the internals of babel.

Also, was the code in a working state with the original babel 6 release (eg, is this a regression) or was upgrading the decorators de-prioritized due to the changing spec (eg. not yet made to work)?

Thank you for all your help and quick responses. Really great!

@loganfsmyth

This comment has been minimized.

Member

loganfsmyth replied Nov 22, 2015

@kmalakoff Using Babel 6 with npm@2.x is not recommended because transpiling performance can be degraded and Babel startup time is absolutely degraded. Babel 6 has a significantly more complex dependency graph and it is only performant with npm@3.x's flattening.

As far as I know, decorators have never worked in 6.x and this added clearer messaging around them. The error you mentioned is mentioned in https://phabricator.babeljs.io/T2702 and appears related to exporting classes.

Debugging Babel no different from any other node application. You can use node-inspector and breakpoints.

Our support channels are documented in our README:

For questions and support please visit the Slack community or StackOverflow.

If you have any other dev questions, please direct them to Slack. Mostly only the core team responds to comments on Github and we aren't that many people. Using Slack helps spread the load around a bit more.

@kmalakoff

This comment has been minimized.

kmalakoff replied Nov 22, 2015

@loganfsmyth thank you for all the information...I'll use your links and move my questions over to Slack or StackOverflow to distribute the load.

Totally understand about babel going with the newest npm, but I'm not going to move over to npm@3.x until it has fixed it's performance. I also as part of my workflow, I use git repos inside of my node_modules folders so npm@3.x 's new behavior of not installing when it encounters git is also a blocker for me upgrading. Plus, as a minor point, I'm not a fan of the flat hierarchy because it is hard to find modules in my text editor among all of the uncontrolled module noise (but when I move over, I'll see how my editor handles search better). I'll eventually move over, but not until there are good solutions for the first two problems.

At least I now know why david isn't working to detect changes in the plugins and babel's position on recommended npm versions.

Much appreciated for everything...

@forivall

This comment has been minimized.

Contributor

forivall replied Dec 9, 2015

@kmalakoff https://docs.npmjs.com/misc/config#global-style to turn off the flat hierarchy style.

@kmalakoff

This comment has been minimized.

kmalakoff replied Dec 9, 2015

@forivall thanks for the link Jordan! Just what I was looking for 👍

@quarterto

This comment has been minimized.

Contributor

quarterto replied Jan 2, 2016

Please sign in to comment.