-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Pathway to getting rid of hand-crafted .d.ts files #7402
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
Conversation
|
||
import { encodeEntry } from '../../../lib/stega'; |
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.
Thanks, this will fix #7401!
One thing might be worth doing is to add an alias to each tsconfig.json
, e.g.
"compilerOptions": {
"paths": {
"@/*": ["./src/*"]
}
then here you can use the alias path...
import { encodeEntry } from '@/lib/stega';
Personally, I find this easier to rationalize the file structure, when importing higher up the tree. This is definitely not required, but something to consider.
Thanks again for your awesome contributions!
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.
Closing this in favor of #7411 |
This PR addresses type-related issues discussed in #4987 and paves the way to a more type-safe codebase.
What this PR does
"build:esm"
script of each package now emits TypeScript declarations indist/esm
. It does this by running babel and tsc in parallel."types"
field that points todist/esm/index.d.ts
🎉tsconfig.json
file that extends a common base. This allows us to use proper project references instead of treating everything as one big project.stega.ts
was in the wrong package) and adds missing types for thesemaphore
npm package.What this PR does not do
This PR does not change any of the handwritten types defined in
decap-cms-core
. It only converts the/index.d.ts
file intosrc/types/index.ts
.Moving forward from here
The plan is to create a follow-up PR (once the new system is in place) that will replace the handwritten public types with the internal ones. With this PR as foundation, it will also be much easier to gradually convert more and more
.js
files into.ts
files.I would love to hear your feedback and if you think that this is the right way to tackle this.