Skip to content
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

Standard package.json key for .ts files #12561

Open
appsforartists opened this issue Nov 29, 2016 · 9 comments
Open

Standard package.json key for .ts files #12561

appsforartists opened this issue Nov 29, 2016 · 9 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Community Tooling This might be better handled by tooling from the community instead of built into TypeScript Suggestion An idea for TypeScript

Comments

@appsforartists
Copy link

appsforartists commented Nov 29, 2016

A common TypeScript module structure looks like this:

src/index.ts
dist/index.js
dist/index.d.ts

and a package.json that looks like this:

  "main": "dist/index.js",
  "types": "dist/index.d.ts",

There's a convention to use the package.json key jsnext:main to point to a variant of main that uses ES2015 module syntax. Can we develop a similar convention to point at .ts files, e.g. typescript:main?

Consider a TypeScript project that is sharded across many microlibraries (e.g. my-project-core, my-project-thing-plugin, my-project-other-thing-plugin). I'd like to be able to configure my bundler to import from src/*.ts files for any module whose name starts with my-project. Otherwise, it will be looking in dist/*.js and I'll have to rebuild the plugins any time I make changes in them.

Of course, I could use jsnext:main for this purpose now, but any consumers who aren't using TypeScript would get syntax errors for any files that contained TS-specific syntax like types. Similarly, I could make up my own package.json key and configure my bundler to look there first, but it behooves the community to have a convention here. That will allow bundlers like Webpack, Browserify, Rollup, and Pundle to look in the right place by default.

@mhegazy mhegazy added the Question An issue which isn't directly actionable in code label Dec 16, 2016
appsforartists added a commit to material-motion/material-motion-js that referenced this issue Dec 20, 2016
Summary:
I checked out a fresh copy of the repo to ensure that it could pass CI.  Here are the changes I made:

- Moved the CI scripts from .travis.yml to package.json for consistency.  It's nice to be able to type `yarn run ci` to run the same suite as Travis.
- Ran `build` before `test`, to ensure any intra-repo dependencies are available in the dist folder for their siblings, as prescribed in package.json.  If we had something like typescript:main, we could skip this step (microsoft/TypeScript#12561).
- Fixed all the errors the linter complained about.  Since a few packages were written before the linter existed, there were conflicts between their style and its.

Reviewers: O3 Material JavaScript platform reviewers, #material_motion, O2 Material Motion, markwei

Reviewed By: #material_motion, O2 Material Motion, markwei

Tags: #material_motion

Differential Revision: http://codereview.cc/D2395
@appsforartists
Copy link
Author

This may be a Feature Request more than a Question. tsc and/or Language Services should follow the same rule, otherwise autocomplete across packages would be broken until a new build occurs.

@DanielRosenwasser DanielRosenwasser added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Community Tooling This might be better handled by tooling from the community instead of built into TypeScript In Discussion Not yet reached consensus and removed Question An issue which isn't directly actionable in code labels Jan 6, 2017
@blakeembrey
Copy link
Contributor

Side note (in case anyone else references the OP): the types field would usually point to dist/index.d.ts and not src.

@appsforartists
Copy link
Author

@blakeembrey fixed.

@appsforartists
Copy link
Author

appsforartists commented Jan 7, 2017

I have this working in both Pundle (http://codereview.cc/D2470) and Webpack (http://codereview.cc/D2472).

And I'm considering opening PRs against RxJS, Cycle, xstream, and Angular to test it with common packages.

@DanielRosenwasser
Copy link
Member

I don't see the harm in it, but I'm not sure whether or not I understand the implications.

Consider a TypeScript project that is sharded across many microlibraries (e.g. my-project-core, my-project-thing-plugin, my-project-other-thing-plugin). I'd like to be able to configure my bundler to import from src/*.ts files for any module whose name starts with my-project. Otherwise, it will be looking in dist/*.js and I'll have to rebuild the plugins any time I make changes in them.

The thing is that if I'm not mistaken, this will still require a full type-check across all of your code (though it can avoid scanning/parsing/binding/sometimes emitting for individual files). @mhegazy is that correct?

@mhegazy
Copy link
Contributor

mhegazy commented Apr 24, 2017

I do not think sharing sources between projects is something i would recommend. .d.ts files are meant for the sharing scenario. jsxnext:main is meant for bundelers, and is already well defined; but this is a different scenario.

@RyanCavanaugh RyanCavanaugh added the Suggestion An idea for TypeScript label Aug 20, 2018
@RyanCavanaugh RyanCavanaugh removed the In Discussion Not yet reached consensus label Mar 6, 2019
@trusktr
Copy link
Contributor

trusktr commented Jun 6, 2020

@mhegazy Sharing sources is the only way to get around the problems listed in #35822.

@appsforartists
Copy link
Author

I'm looking at adding Vite to my workflow, and once again this seems like a good solution.

Here's the problem: Vite shortcircuits typechecking to make UI iteration faster. To do that, it needs to know what sources you have under control, so it can watch them for changes without waiting for tsc to run. I still want tsc to do typechecking, I just don't want it on the critical path for experimenting with UI. My current setup has gotten slow enough that I find myself waiting for tsc when I'm testing visual changes.

It appears Vite has a resolve: mainFields: [] setting to control which part of package.json it uses for resolution. If I add something like "typescript": "src/index.ts" to my package.jsons (and to my Vite config), I can tell Vite how to navigate the source in my monorepo, while still leaving "module": "dist/index.js" for TypeScript to generate for downstream consumers.

cc @yyx990803 @patak-dev

@appsforartists
Copy link
Author

That's how I ended up adding Vite to my monorepo.

  • src/index.html points to ./mount.tsx.
  • dist/index.html points to ./mount.js. (dist is generated by tsc and sed.)

When vite serve is running, I include typescript in mainFields, and I've added a "typescript": "src/index.ts" entry to the package jsons in the monorepo. That puts all the JS I've authored on the Vite fast path during development, but keeps tsc in the loop to typecheck before publishing.

Here's an example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Community Tooling This might be better handled by tooling from the community instead of built into TypeScript Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

6 participants