-
-
Notifications
You must be signed in to change notification settings - Fork 4
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
fix: make types usable in CommonJS #44
Draft
fasttime
wants to merge
6
commits into
main
Choose a base branch
from
fix-cjs-types
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+25
−7
Draft
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
ade2a29
fix: make types usable in CommonJS
fasttime f489f6b
Merge branch 'main' into fix-cjs-types
fasttime 9c3c05a
use local `@types/css-tree` package
fasttime 89c1a09
don't use `node_modules/@types/css-tree` in development
fasttime 2a8cb3a
use `node_modules` types instead of local typings
fasttime 89d90c0
remove outdated `@types/eslint`
fasttime File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
/** | ||
* @fileoverview CommonJS type import test for ESLint CSS Language Plugin. | ||
* @author Francesco Trotta | ||
*/ | ||
|
||
//----------------------------------------------------------------------------- | ||
// Imports | ||
//----------------------------------------------------------------------------- | ||
|
||
import "@eslint/css"; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The generated dist files
dist/cjs/index.d.cts
anddist/esm/index.d.ts
contain type imports fromcss-tree
, for example:css-tree does not contain built-in types, so it seems good to add a dependency on the types package. If we don't want to add a runtime dependency I think we should at least keep
@types/css-tree
in the devDependencies so that the types test can validate our own types against the css-tree types.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I already have my own types for
css-tree
here:https://github.com/eslint/css/blob/main/typings/css-tree.d.ts
(The
@types/css-tree
package is very out of date and was causing errors, so I created my own.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see now. What do you think about copying the
typings
directory todist/typings
and changing the type imports in TSDoc to use local paths instead of the package name, e.g.import("../typings/css-tree")
instead ofimport("css-tree")
? I think this would be the solution with the best compatibility for both npm and jsr if we don't want users to install the css-tree types by themselves.Note:
css-tree.d.ts
would have to be minimally changed by removing the module declarationdeclare module "css-tree" {
...}
. I'm not sure if there's another way, but I can check.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems messy to me. I'd then need to manually apply all the types to the CSSTree API to get intellisense and type checking working.
This must already be a solved problem in the TypeScript ecosystem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this approach type checking will work without having to apply the CSSTree types manually to JavaScript files - as long as the TSDoc comments are modified. I'm not sure though about intellisense.
Another solution is packaging the updated version of
@types/css-tree
as a local directory, liketypings/css-tree/
. Instead of the npm version,package.json
could specify to install the contents of the local directory with"@types/css-tree": "file:./typings/css-tree"
. This will not require changing the sources and it should work well for npm as well. I'll just need to check how to get the same settings with jsr since jsr doesn't usepackage.json
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I mean is, when I do something like
import { parse } from "css-tree"
, then I won't get any type checking or intellisense forparse()
if we remove thedeclare module "css-tree"
from the type definitions.The
package.json
approach seems like a better option to me. I'm not too worried about JSR at this point, as I'm not sure there's much usage there.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I got everything working now. Apart from installing
"@types/css-tree"
from the localtypings
directory I changedtsconfig.json
to avoid a namespace conflict in Bun, and it looks like intellisense is working fine in VSCode.As for jsr, it seems that there is no standard to install a local types only package: they expect packages to include their own types. So the type mappings must be done directly by the runtime. For example in Deno using the
@ts-types
annotation. I'm not sure if we should mention this in the docs since we don't provide specific instructions for Deno or jsr at the moment.