-
-
Notifications
You must be signed in to change notification settings - Fork 119
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
Class private methods are not enabled. #419
Comments
I've seen it recently after I upgraded tracked-built-ins to v2. I have no idea what causes this error, so I raised an issue here: tracked-tools/tracked-built-ins#204 |
that's the library where am seeing this, too. It's not tracked-built-ins' fault tho. We should be able to use private properties and methods in our apps -- if we do, we get the same error. |
oh! I just tested this, that's not true!!! private methods work just fine in the host app. ok, so this bug with ember-cli-babel is that addons are not appropriately inheriting the browserlist or targets? 🤔 maybe? |
Another option, smith with TS compilation as add-on source is .ts EDIT: I may be wrong as there are .js files |
tracked-built-ins is a V1 addon, so TS compilation happens as a result of the app telling the addon to compile... which.. is handled by the host's ember-cli-babel 🤔 I think ember-cli-babel has a misconfiguration for addons 🤔 |
Is there a minimal reproduction for this? Can someone give me a repo to clone (with either a lockfile that demonstrates the issue, or checked in |
on it |
@NullVoxPopuli I'm already pushing a repro repo. |
Here is my repro: NullVoxPopuli/repro-for-emberjs-19790#2 |
Lulz. Here's mine. Same. |
Additional info to make things extra complicated: we’re now consuming latest v. of |
Debugged this with @chriskrycho a bit. The main issue (we believe) is that ember-cli-babel is always adding Path forward in this repo is to change that guard above to only add the class-properties plugin when it is needed (possibly by using Unfortunately, we also need to land some fixes to ember-data LTS versions. Specifically, the version of
At the moment that is using rollup@^1.12.0, via these packages: tldr; we need to bump @ember-data/-private-build-infra to use broccoli-rollup@5 (which allows us to upgrade to latest rollup, which should support the syntax we need). |
Looks like [email protected]+ will have the newer version (landed in emberjs/data@325ce04), but not in 3.24/3.28 just yet. |
This gets us on the relevant latest versions of *all* of our dependencies, transitive and otherwise, including the latest versions of `@babel/preset-env` and `ember-cli`, which together trigger the build error seen in #204 and emberjs/ember-cli-babel#419. **This commit fails intentionally.** The follow-on commit will fix it, and the CI history will thereby act equivalent to a fixed failing test.
looks like this happens with optional chaining as well (from v2 addons) |
hello, is there any workaround for this problem? |
not that I know of -- we have to fix ember-cli-babel |
I attempted this: https://github.com/babel/ember-cli-babel/compare/master...NullVoxPopuli:idk?expand=1 but I get errors from within babel with the
|
I've also run into issues with this. Forcefully including the plugin in ember-cli-build then results in an issue caused by an outdated pinned version of Forcing a resolution allowing newer runtimes solves this issue but triggers another issue Not sure what the way forward is, but I assume having a pinned version edit: fyi, pinning |
If you read @rwjblue's explanation above, the things you're seeing will make sense: it's basically because the transitives of those earlier values end up including earlier versions of the database which preset-env uses to determine which plugins are required. The problem, most briefly, is that for it to work correctly, all of the class fields plugins are required together if any of them are required, and ember-cli-babel was only adding one of them—we really just want to not add any of them automatically (the reasons we were doing that historically are no longer relevant), but dropping them broke Ember Data which was accidentally implicitly relying on what ember-cli-babel was doing. The “fix” here is: don't update dependencies which are causing this breakage until we get out releases of ember-cli-babel and Ember Data which resolve the issue. Which is a bit slowed because of (a) the Ember 4 releases and (b) this week being American Thanksgiving! 🦃 🥧 🇺🇸 (Given which I'm going to vanish back into non-OSS land now. 😉) |
What should those of us who don't use ember-data do? Is there PR we can point at, etc? Kind of a shame for ember data to be such a blocker. 🤔 |
It's just this babel issue is holding up a lot of work for me, and I don't like that something I don't use is blocking :( oh, I just saw @nickschot's comment -- gonna try some pinning so I can at least do something. :D Update: no pinning works. |
This is immensely frustrating -- pretty much can't work atm. :( Here is my last attempt, where I just started deleting a bunch of the legacy crap: 0f1b995 but, the overall problem remains where the host app's targets aren't considered when running babel:
I know it's more efficient to only have each addon's needs use specific plugins, as each additional plugin can add compile time, but this has fealt very brittle, and I feel lost / frustrated / upset. 😢 |
@NullVoxPopuli I promise I have no subject-matter expertise here. Reading above:
My reading here is that the fix is to not add any of the class field plugins in e-c-babel, but that fix was blocked by a fix to Ember Data because the e-c-babel fix broke Ember Data. |
I am writing a generic typescript package using |
I tried that here, with excludes and no success: 0f1b995#diff-4d3a8edb07aff5a7c43d8692de88a4eb83b327e2a352633699ba4afb9b753b6aR21 🤷 |
@rwjblue or @chriskrycho are you able to put up a PR with the fix? |
Pinning @babel/helper-create-class-features-plugin to 7.14.6 seems to have fixed this for me |
Thanks to emberjs/ember-cli-babel#419 (comment) from @VinceJones, tests run again, and this work is no longer blocked by emberjs/ember-cli-babel#419 BREAKING CHANGE: this package now requires ember-auto-import@v2
Thanks, @VinceJones !! I confirm that in NullVoxPopuli/ember-statechart-component#149 |
but it doesn't help with embroider 🤔 https://github.com/NullVoxPopuli/ember-statechart-component/runs/4412492851?check_suite_focus=true |
it seems there is no way to make resolutions work with ember-try + npm -- gonna try switching to yarn |
# [3.0.0](v2.3.7...v3.0.0) (2021-12-05) ### Bug Fixes * **deps:** update dependency tracked-maps-and-sets to v3 ([40618e9](40618e9)) ### chore * drop support for node 12 ([b1b3c4c](b1b3c4c)) * **ci:** update test matrix ([91de3bb](91de3bb)) * **deps:** pin @babel/helper-create-class-features-plugin ([1a8111b](1a8111b)), closes [/github.com/emberjs/ember-cli-babel/issues/419#issuecomment-985735309](https://github.com//github.com/babel/ember-cli-babel/issues/419/issues/issuecomment-985735309) ### BREAKING CHANGES * node 12 is no longer supported * **ci:** drop support for ember 3.26 * **deps:** this package now requires ember-auto-import@v2
in ember-statechart-component, I was able to get passed this issue by... not using tracked-built-ins. I still consider this issue to be an ecosystem-wide outage tho |
ember-cli-babel ruins lives :( (or maybe just babel) Blocked by: NullVoxPopuli/ember-statechart-component#149 which is in-turn blocked by: emberjs/ember-cli-babel#419 which is then blocked by ember-data... *for some reason*. (I don't use ember-data here, so idgaf) Further work is blocked by embroider-build/embroider#1038
rwjblue and I are going to try to get this knocked out tomorrow; in the meantime, folks may be able to work around it by pinning |
Historically, we only add the `@babel/plugin-proposal-class-properties` so that we make sure the ordering is right with the decorators proposal (otherwise, it can end up compiling in the wrong order). With a recent version of `@babel/preset-env` and, transitively, `caniuse-lite`, this resulted in cases where we added that plugin but *not* related plugins for private class properties, which in turn triggered a Babel assertion about not adding the properties together as appropriate when the caniuse database (correctly) reported that . The fix is: 1. Bump to a more recent version of `@babel/preset-env`, which comes with a correspondingly bumped version of `caniuse-lite`, which in turn correctly understands what the latest versions of targeted browsers are. 2. Include in `ember-cli-babel` itself a check for whether we even *need* to add the plugin, and only provide it when the provided `targets` indicate that they require it. Resolves emberjs#419
Historically, we only add the `@babel/plugin-proposal-class-properties` so that we make sure the ordering is right with the decorators proposal (otherwise, it can end up compiling in the wrong order). With a recent version of `@babel/preset-env` and, transitively, `caniuse-lite`, this resulted in cases where we added that plugin but *not* related plugins for private class properties, which in turn triggered a Babel assertion about not adding the properties together as appropriate when the caniuse database (correctly) reported that . The fix is: 1. Bump to a more recent version of `@babel/preset-env`, which comes with a correspondingly bumped version of `caniuse-lite`, which in turn correctly understands what the latest versions of targeted browsers are. 2. Include in `ember-cli-babel` itself a check for whether we even *need* to add the plugin, and only provide it when the provided `targets` indicate that they require it. Resolves emberjs#419
Historically, we only add the `@babel/plugin-proposal-class-properties` so that we make sure the ordering is right with the decorators proposal (otherwise, it can end up compiling in the wrong order). With a recent version of `@babel/preset-env` and, transitively, `caniuse-lite`, this resulted in cases where we added that plugin but *not* related plugins for private class properties, which in turn triggered a Babel assertion about not adding the properties together as appropriate when the caniuse database (correctly) reported that . The fix is: 1. Bump to a more recent version of `@babel/preset-env`, which comes with a correspondingly bumped version of `caniuse-lite`, which in turn correctly understands what the latest versions of targeted browsers are. 2. Include in `ember-cli-babel` itself a check for whether we even *need* to add the plugin, and only provide it when the provided `targets` indicate that they require it. Resolves emberjs#419
I'm still seeing this with Ember 4.3.0 with npm pdfjs-dist |
Do you have the latest ember-cli-babel, and only one copy in your whole package graph? |
From what I've seen this issue can still occur in certain situations when a newer than 7.12.x Is this what you're seeing too @BryanCrotaz or is there another path to breakage? |
This is what I see:
|
Hello @BryanCrotaz! |
I went through and upgraded all my addons. |
Hi @BryanCrotaz , I am doing the pdfjs-dist integration and meeting the same issue. I realised it is actually ember-auto-import issue as imported node module package (e.g. pdfjs) are transpired, instead of by ember-cli-babel, are by "babel-loader" with webpack when being imported by ember-auto-import. It should be working out-of-box as private methods are officially supported in babel/preset-env, however there is a bug preventing that. After I manually implement the babel-loader in the ember-cli-build the integration is working now. Here is my test app. |
I just upgraded tracked-built-ins in an addon and am getting this error:
but, what's weird, is that I've worked on tracked-built-ins with private methods... and this wasn't an issue at all.
My ember-cli-babel appears up to date:
and browserslist seems to be up to date as well.
The text was updated successfully, but these errors were encountered: