Closed jharris4 closed 4 years ago
@kentcdodds Thanks for reviewing and approving!
Are two approvals needed for a PR to be merged? I don't see anything in CONTRIBUTING.md.
Would love to be able to use this change once it's merged and released to a new beta... ;-)
I'm not really a maintainer. I don't know what the process for things like this are in this repository. So I'll wait for a maintainer to review this.
One concern I have with this change is that it feels really arbitrary what config options babel-eslint would be allowing and not allowing.
A babel config is a babel config regardless of where it comes from. The only thing changing here is where this config gets specified, but the available settings/options are exactly the same.
I believe both TypeScript and typescript-eslint require a
tsconfig.json
, and this feels like a really similar case to me.
A lot of tools do follow the convention of requiring a configuration file to be named a certain way or for it to be in a specific location. There's nothing wrong with that per se, but it is short sited to force this to be the case (in my opinion) since it limits interoperability with other tools.
Better to support multiple options and let users or build tool authors pick the approach that works best for them... ;-)
@hzoo @kaicataldo Is it possible to merge this and release that as another v11 beta? this way we could test this strongly needed feature... Thanks
@axten, yes it'd be great to get this merged, and then I could tackle making another PR for 11.x to fix the eslint 6.3 issues...
anything new here? we're still unable to use private class methods because of this not been merged...
@axten Private methods are broken for another reason. If you are already using private methods with Babel, then babel-eslint
should already be able to parse them.
We don't have a babel config file, so we're unable to use any newer babel plugin since months. Private class methods are not working for us until #801 is released in the v10.x branch or #768 lands in the v11.x branch.
@axten it's not ideal, but since there hasn't been a new release of this package in quite some time we've been using a fork with this PR included.
It's based off the 11.x
branch, and you can find it on npm as babel-eslint-fork
.
We've been using it for a few months now without any issues.
thank you, I will have a look...
@axten it's not ideal, but since there hasn't been a new release of this package in quite some time we've been using a fork with this PR included.
It's based off the
11.x
branch, and you can find it on npm asbabel-eslint-fork
.We've been using it for a few months now without any issues.
I'm using it but I got the same error: "This experimental syntax requires enabling the parser plugin: 'classPrivateMethods"
@hadnet I haven’t tried classPrivateMethods, but it sounds like you maybe need to tweak your babel config?
If you share your config and a sample of code using private class methods I can take a look...
@hadnet I haven’t tried classPrivateMethods, but it sounds like you maybe need to tweak your babel config?
If you share your config and a sample of code using private class methods I can take a look...
const developmentEnvironments = ['development', 'test'];
const developmentPlugins = [require('react-hot-loader/babel')];
const productionPlugins = [
require('babel-plugin-dev-expression'),
// babel-preset-react-optimize
require('@babel/plugin-transform-react-constant-elements'),
require('@babel/plugin-transform-react-inline-elements'),
require('babel-plugin-transform-react-remove-prop-types')
];
module.exports = api => {
// see docs about api at https://babeljs.io/docs/en/config-files#apicache
const development = api.env(developmentEnvironments);
return {
presets: [
[
require('@babel/preset-env'),
{
targets: { electron: require('electron/package.json').version }
}
],
require('@babel/preset-flow'),
[require('@babel/preset-react'), { development }]
],
plugins: [
// Stage 0
require('@babel/plugin-proposal-function-bind'),
// Stage 1
require('@babel/plugin-proposal-export-default-from'),
require('@babel/plugin-proposal-logical-assignment-operators'),
[require('@babel/plugin-proposal-optional-chaining'), { loose: false }],
[
require('@babel/plugin-proposal-pipeline-operator'),
{ proposal: 'minimal' }
],
[
require('@babel/plugin-proposal-nullish-coalescing-operator'),
{ loose: false }
],
require('@babel/plugin-proposal-do-expressions'),
// Stage 2
[require('@babel/plugin-proposal-decorators'), { legacy: true }],
require('@babel/plugin-proposal-function-sent'),
require('@babel/plugin-proposal-export-namespace-from'),
require('@babel/plugin-proposal-numeric-separator'),
require('@babel/plugin-proposal-throw-expressions'),
// Stage 3
require('@babel/plugin-syntax-dynamic-import'),
require('@babel/plugin-syntax-import-meta'),
[require('@babel/plugin-proposal-private-methods'), { loose: true }],
[require('@babel/plugin-proposal-class-properties'), { loose: true }],
require('@babel/plugin-proposal-json-strings'),
...(development ? developmentPlugins : productionPlugins)
]
};
};
When I set my eslintrc to 'parser': 'babel-eslint-fork', I got another error: "Parsing error: params is not iterable."
When I'm using the arrow function way no error at all.
@hadnet I don’t see anything obviously wrong, and I see there’s a related issue: https://github.com/babel/babel-eslint/issues/728
I’m traveling for the holidays but will give it a try when I’m back at my computer.
In the meantime, have you tried switching the order of the private-methods
and class-properties
plugins so that class properties is first?
@hadnet I finally had some time to look into using the @babel/plugin-proposal-private-methods
, and it's installing/activated correctly using this plugin, but I get an error when linting:
0:0 error Parsing error: params is not iterable
It looks like this is a known issue https://github.com/babel/babel-eslint/issues/749, and it seems that it's blocked until a PR gets merged into estree...
@hzoo @kaicataldo @nicolo-ribaudo this project seems to be unmaintained. I cannot understand why this don't get merged and released. Several people are waiting for this since july...
Hey there, apologies for not getting back to you sooner. All active development has moved to the main Babel monorepo. You can track our progress here. Do you mind making an issue with your proposal in that repository so we can evaluate it in the context of our v8 release plans?
Closing this now that https://github.com/babel/babel/pull/11639 has been released. Thanks for contributing!
As discussed in a comment at the end of #711 I have a use case for the following:
The change to the code in this PR was trivial and I confirmed locally that it does work as expected, allowing me to pass in a custom babel config without using a babel config file.
Writing the test case took a couple of hours as I had to figure out a way to show that the change does exactly what is expected.
Feedback on improving/cleaning-up the tests would be more than welcome...