Comments (16)
project: true
?
from typescript-eslint.
Got hit by this as well. I'd like to use the new no-unnecessary-type-assertion
rule, but is unable to due to our repo being a monorepo, with each package having its own tsconfig.
extending either tsconfg.node.json
or tsconfig.browser.json
in the root of the repo (also using composite projects, fwiw).
I think the rationale here was to avoid generating some objects needed to support the type checking if the user doesnโt request them.
Can I say "please generate the objects needed, I want type info"? Seems like something that should be a boolean turning "look up closest tsconfig.json" on or off
from typescript-eslint.
@bradzacher Thanks for the heads up! I'll give the JS migration a shot throughout my projects.
individual configs must be written as a commonjs module
However, are ESM config files expected to be supported at some point? One of the reasons why we started using YAML configuration was to help avoid mixed commonjs/esm codebases
from typescript-eslint.
That RFC was added in 2019, before ESM was properly supported by node. ESLint has since added support for the .cjs
extension for the config file - which you can (and should) use if you've got an ESM project.
The ESLint team is currently discussing the migration to ESM. It's a complicated topic to navigate for such a prominent package.
from typescript-eslint.
from typescript-eslint.
I think the rationale here was to avoid generating some objects needed to support the type checking if the user doesnโt request them.
from typescript-eslint.
Yeah, something like that'd be perfect :)
from typescript-eslint.
Any updates on this?
from typescript-eslint.
We won't ever auto-detect the project without a config item. As soon as we do that, we would force every user to go through a complete typescript compile by just including one of rules.
A lot of users currently avoid rules that require typeinfo because they can cause large perf impacts on some codebases.
However with something like project: true
maybe we could use a lookup algorithm instead of requiring a specific config setup.
This can be worked around using tsconfigRootDir
:
module.exports = {
parserOptions: {
project: './tsconfig.json',
tsconfigRootDir: __dirname,
},
}
https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/parser#configuration
If you don't specify tsconfigRootDir
, we default to using the CWD because that's how the rest of node works, and how the typescript compiler works (I looked through typescript's code to see what they do).
i.e. if you were to unravel all of our code and typescript's code, you'll see that essentially the algorithm for resolving the provided path is essentially:
const rawConfig = fs.readFileSync(
path.resolve(
process.cwd(),
options.tsconfigRootDir || process.cwd(), // note path.resolve(process.cwd(), process.cwd()) === process.cwd()
options.project,
),
);
from typescript-eslint.
The idea was not to "autodetect when a rule that needs it is included", but to have an option where which tsconfig.json
is used to check the file is not hardcoded in the config, but looked up in relation to the file being linted.
The requirement to be able to specify __dirname
also prevents shared configs from being used via json or package.json
configs and the individual configs must be written as a commonjs module.
It is a possible workaround, but one that is harder to make use of than an option to enable searching upwards for a tsconfig.json
; and I still don't know what happens if different files are linted with different effective tsconfig.json
files, as would happen in a monorepo eslint pass.
from typescript-eslint.
what happens if different files are linted with different effective tsconfig.json files, as would happen in a monorepo eslint pass
If you have a tsconfig.json in your root (which I think you need for vscode to handle it??) then it will work as expected as long as your compiler options are consistent between projects in a monorepo.
This is how we've got it setup in this repo - a root tsconfig which defines the compiler options and then tsconfigs for each project which extend that root config and define the output paths and includes etc.
individual configs must be written as a commonjs module
I didn't think this was a huge problem - from the eyes of your codebase, it's 2 letters in an extension plus a one line change?
Don't get me wrong, I do understand that it's not a perfect solution, but it's a workaround for now.
Happy for someone to PR a change for this though.
from typescript-eslint.
This would be extremely useful in monorepos, where you have some projects with per-project unique rulesets and you want to be able to run eslint from the monorepo root and the projects roots as well. I prefer yaml for configuration and __dirname
is not an option in that case
from typescript-eslint.
I prefer yaml for configuration
@bencelang I have bad news for you.
YAML configs are going away in a future version of ESLint (as are JSON configs).
https://github.com/eslint/rfcs/tree/main/designs/2019-config-simplification#the-eslintconfigjs-file
I would migrate away from YAML to JS to avoid future pain.
from typescript-eslint.
This issue is very old but very juicy - I'd love to be able to shorthand project: true
instead of specifying other files. Adding to the v6 milestone. ๐
Edit: this might land in v5 anyway - in which case I'll remove it from the milestone. v6.0.0 is just the latest version I'd be happy with this shipping in.
from typescript-eslint.
It's worth noting that this would cause some perf regressions because disk lookups are going to be more expensive than a static config. Also depending on project setup you might have some "useless" tsconfigs that we waste time interrogating before finding the correct tsconfig for a file.
In terms of the config style - project: true
probably isn't quite good enough for all usecases. For example it's not uncommon to define tsconfig.eslint.json
(or other named tsconfigs).
Maybe we'll need to do something like this:
project: true
- just use the closesttsconfig.json
on disk for each linted file.project: { allowedTsconfigNames: FileName[], ignoredTsconfigs: RelativePath[] }
allowedTsconfigNames
to specify the set of names you want us to search (default['tsconfig.json']
ignoredTsconfigs
to ignore specific tsconfigs you know would be useless.
The complicated thing in this algorithm will be determining which tsconfig to use and cache it. It's completely possible for two files in the same folder to be covered by different tsconfigs - so we can't just assume all files in a given folder are covered by the same tsconfig. This means that for every single file we'll need to do a lookup to figure out the tsconfig to use. I believe we can use TS's infra to parse the tsconfig and get the list of files it contains without having to go through the expensive program generation (which should save some time).
For CLI runs we can assume tsconfigs are constant and aggressively cache all this stuff so we only need calculate it once per tsconfig. It should be relatively simple to implement for this usecase.
For persistent IDE runs it's going to be a lot more complicated because we can't attach disk watchers and we can't assume that tsconfigs are static in content or location. I don't know the best way for us to handle this - maybe we need to investigate how vscode does it? I assume they probably have file watchers. We have invalidation logic which handles the "tsconfig was changed" usecase, but I don't know how we can efficiently handle the "tsconfig was added/moved" usecase without watchers. Maybe we'll just need to fuzzily cache for some time period for perf reasons and hope that it doesn't cause too much weirdness? Not sure what the best solution will be!
from typescript-eslint.
project: true probably isn't quite good enough for all usecases
something like this: ...
Agreed, and that feels like a followup issue to me ๐. Let's get true
to "just" work out of the box for users first, and then add in more controls around it?
fuzzily cache for some time period for perf reasons
Yeah, I've been playing with this. I verified locally that createParseSettings
is called whenever a file is linted in VS Code, so as long as the "does this tsconfig.json
file exist on disk?" cache doesn't last more than a few dozen milliseconds, I feel comfortable going with a straightforward approach like that.
from typescript-eslint.
Related Issues (20)
- Docs: jot down comon patterns for rule development HOT 1
- Bug: [unbound-method] Does not fail for destructured parameters HOT 3
- Repo: Set up v8 alpha/canary version publishing
- Bug: [explicit-function-return-type] false positive on defaulting parameters
- [disable-type-checked-config] missing `@typescript-eslint/explicit-function-return-type` rule HOT 3
- Bug: [no-floating-promises] False positive for spread arguments in then() HOT 3
- Docs: Document how to import and configure the parser for flat config HOT 2
- Repo: CI failing to publish v8 canaries
- Docs: Missing `yarn set version` step in "Local Linking" instructions with yarn 1 HOT 1
- Repo: Build failure on main: explicit-function-return-type in createProjectService.ts HOT 2
- Rule proposal: Ban method override type narrowing HOT 3
- Enhancement: [no-unused-vars] Update for ESLint 9 defaults
- Enhancement(utils): Update types ESLint v9 Linter class (flat config) HOT 6
- Enhancement(rule-tester): assert suggestion messages are unique HOT 1
- Enhancement(utils): Swap FlatESLint-ESLint, FlatRuleTester-RuleTester in API
- Repo: Incorporate void check into isNullableType?
- Bug(utils): deprecated helpers for ESLint context are not exported HOT 1
- Enhancement: [ban-types] Split into default-less no-restricted-types and more targeted type ban rule(s)
- Rule proposal: Prefer array.at(...) over array[...] as T | undefined HOT 2
- Docs: wrong example in `no-unnecessary-boolean-literal-compare`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typescript-eslint.