Comments (4)
You can just point your package.json "main"
or "exports"
to the .ts files, and consumers with --moduleResolution bundler
should be able to pick those up just fine. However, if your overall project size is big enough, note that .d.ts
files are more efficient for the type checker to consume, so the structure you’re envisioning may come with a bit of a compile-time performance penalty.
to get type hinting work in the IDE, only to complain it is not constructible later on with the
new This()
When this happens, it means either your own tsconfig is wrong, or the package you’re consuming has typing/package.json problems. This is why I made https://arethetypeswrong.github.io. Next time you hit a problem like that, I’d encourage you to run it, and file an issue with the library if it shows configuration issues.
I see nothing in the docs
I’m working on them; see microsoft/TypeScript#52593 for tracking and https://gist.github.com/andrewbranch/79f872a8b9f0507c9c5f2641cfb3efa6 for the in-progress draft.
from example-subpath-exports-ts-compat.
Thank you very much for this information. It will be greatly helpful!
from example-subpath-exports-ts-compat.
Hi Bruno,
This repo was intended to show examples for how libraries, who publish JS files to npm, can support users who use a variety of (maybe incorrect) moduleResolution
configurations. Those libraries should always produce .js files, and should not compile with --moduleResolution bundler
themselves. For users who have --moduleResolution bundler
set, node_moduels packages will resolve identically to how --moduleResolution nodenext
would behave in a .mts
file. I don’t think there’s anything unique there for this repo to show. Does that answer your question?
from example-subpath-exports-ts-compat.
Thanks for your answer. I don't know if it answer my question; I might have to re-read a few times 😅!
Basically, what I was looking for is to create TS packages (in the sens of no JS files) to publish in a private (localhost in fact) repository to reuse around in my own projects. Obviously my other projects are also TS projects and down the chain one will be responsible to do the build (bundle, compile, transpile, or whatever that project needs).
I was hoping that my project doing the build could use the TS file from the node_modules
package directly and not use the pre-made ESM or CJS files and mash them again. A bit like having the TS file directly in the project (either duplicated or in a monorepo workspace with pnpm).
Maybe I am overthinking it. Maybe the docs aren't clear on the use case for --moduleResolution bundler
(in fact, I see nothing in the docs, handbook or tsconfig reference about it; there is only the TS 5.0 release note). Maybe I am trying to use a bit too much bleeding edges (or strict) options not compatible with existing tools. In any case, this whole module thing in JS/TS ecosystem is driving me nuts 😂1!
For the moment, I only got a re-use inside a monorepo working using both --moduleResolution bundler
and --allowImportingTsExtensions
.
I'll close this since the goal of the repository was not really what I was asking.
Footnotes
-
A bit of ranting (to let of the steam...) Don't even get me started on a Webpack config written in TS trying to import a plugin... Trying all possible options
import = require()
const = require()
import * as This from 'this'
import This from 'this'
import {This} from 'this'
to get type hinting work in the IDE, only to complain it is not constructible later on with thenew This()
. Then, its just iterative process (including modifyingtsconfig.json
) to get the IDE, ESLint, tsc, ts-node and nodejs all agrees on something that works! But most of the time, I end up having a config that work to get the end result even though someone in the chain is whining something isn't right. ↩
from example-subpath-exports-ts-compat.
Related Issues (7)
- How to publish plain JS+JSDoc library for TypeScript consumers? HOT 1
- Import completion in VSCode HOT 3
- VSCode completion issues inherent to package.json redirect strategy? HOT 2
- Clarify separate types for CJS and ESM in package.json redirect strategy HOT 1
- Parcel to support `package.json#exports` soon
- Question: Why define both main and exports in package.json of types-versions-wildcards HOT 1
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 example-subpath-exports-ts-compat.