@typescript-bot pack this

Heya@andrewbranch, I've started to run the tarball bundle task on this PR at86151e1. You can monitor the buildhere.

Hey@andrewbranch, I've packed this intoan installable tgz. You can install it for testing by referencing it in yourpackage.json like so:

{    "devDependencies": {        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/75621/artifacts?artifactName=tgz&fileId=45DA6FF44370AD15DEFF5E61EDC74241CF262D815E40DE2D87AB199B145FE63502&fileName=/typescript-4.0.0-insiders.20200603.tgz"    }}

and then runningnpm install.

There is also a playgroundfor this build.

After further thought, I do think devDependencies should be excluded by default (we could add a configuration option to include them if enough people really want them). Including them by default means that virtually every project written in TypeScript would get auto-imports for the compiler, which nobody wants. If youdo want to import the compiler API,typescript is either going to be in your"dependencies" or"peerDependencies"—and weshould include peer dependencies by default.

After further thought, I do think devDependencies should be excluded by default (we could add a configuration option to include them if enough people really want them). Including them by default means that virtually every project written in TypeScript would get auto-imports for the compiler, which nobody wants. If youdo want to import the compiler API,typescript is either going to be in your"dependencies" or"peerDependencies"—and weshould include peer dependencies by default.

sometimes we do want to auto import in devDependencies, for example, some test only package. is there some better way to avoid the "typescript" problem? maybe some kind of filter?

Once you manually import your devDependency once, it will be available for auto-import throughout the rest of your project. So... it's kind of already a reverse filter that you configure implicitly as you code.

Is there a way to specifywhichpackage.json to use for this?

I have a monorepo, structured like this:

• apps
  • nextjs
• packages
  • components

Mypackage.json inside ofapps/nextjs has all of my dependencies, such asreact, etc.

However, VSCode only checks therootpackage.json of my monorepo, which has zero dependencies inside of it.As a result, none of the monorepopackages get autoimport.

Is there a way to set the setting to specify apackageJsonPath or something like that?

"typescript.preferences.includePackageJsonAutoImports":"on","typescript.preferences.packageJsonPath":"./apps/nextjs",

@nandorojo are you primarily a TypeScript or JavaScript user? (Or more to the point, is this particular project written in TypeScript?) The expected structure is that each package of a monorepo should have a tsconfig.json file. As a JS user, you can still have a tsconfig.json or jsconfig.json file there, and even just putting{} as its contents should be enough for package.json auto-imports to work. Note that we have an open issue for investigating inferring this structure for JS users without any tsconfig/jsconfig files, but it’s complicated:#45558.

@andrewbranch really appreciate the fast reply.

I'm a TS user exclusively. I tried adding atsconfig.json to eachpackages/* folder as well, but no dice on autoimports.

Interestingly, autoimport does get solved if I duplicate mydependencies fromapps/nextjs/package.json → rootpackage.json'speerDependencies. But it's a definite antipattern to put dependencies in the root of a workspace like that.

I don't mind having atsconfig in eachpackages/* andapps/* folder, but I don't think this solves it for me.

I am able to autoimport my monorepo packages (@beatgig/components does autoimport). But the dependencies fromapps/nextjs, such asreact, still don't autoimport inside ofpackages/*.

Let me know if you need me to clarify anything there, it might be a bit hard to follow.

Are you able to either share the project you’re working in or reproduce this in a little example? The only possible explanation I can think of besides this being a bug is that if we discover too many unused dependencies, we disable the package.json auto imports:

This would happen if you have a bunch of dependencies listed in a package.json but the project in question has not already imported them. You can try toggling this setting toon and see if that makes a difference. Otherwise, go ahead and open a new issue with repro steps. Thanks!

I did already set that toon inside of.vscode/settings.json, actually, but unfortunately it didn't help. I don't think I can share the current repo since it's private, but I'll try to reproduce it in one you can use and will post an issue. Thank you again!

@andrewbranch I have a repro here:https://github.com/nandorojo/vscode-monorepo-autoimport-repro

It's very minimal (these are all the dependencies):

Do you need me to open an issue, or is this sufficient? I added a few comments in the only twots files that should give you what you need.

This is working as intended—react is not listed inany package.json visible topackages/components/index.ts. We filter out transitive dependencies from auto-imports because importing from packages you don’texplicitly depend on is fragile—see#30033 and#38768. You don’t need to addreact to theroot package.json, but it should be inpackages/components/package.json. I believe yarn/npm/lerna will all hoist this to the root node_modules so the dependency isn’t duplicated, so there’s no reason not to specify it as a dependency.

I see, thanks for clarifying.

It works fine if I manually import it, though, so it's as if the autoimport doesn't match the actual behavior. Both the Next.js app and the type checker work without explicitly adding these dependencies to each package.

My hesitation with adding it topackages/components/package.json is that I'll have tons of duplicate items in eachpackage.json when it isn't actually required, either at runtime or for types. I would only add these dependencies to each package to get auto-import to work.

Is there a way to possiblyextend the dependencies fromapps/nextjs? (My guess is there isn't, but just in case...)

I believe yarn/npm/lerna will all hoist this to the root node_modules so the dependency isn’t duplicated, so there’s no reason not to specify it as a dependency.

I agree that practically speaking, since they won't duplicate, there's no real downside to this.

But in a large monorepo with over a dozenpackages/* folders and tons of dependencies, it's a pretty rough DX to copy every dependency into so many places, given that it's all only to get the auto-imports to work.

If there are no intentions to allow transitive dependencies (even behind a flag) for autoimports, then I'll just add each dependency to each subpackage. My guess is, you've thought about the downsides more than I have. But I thought I would leave my thoughts on the DX.

I don't necessarily want all transitive dependencies to autoimport – only the ones I've explicitly put in a subpackage'spackage.json.

I did try explicitly adding these to my monorepo packages, as recommended, and it does solve the autoimports.

However, to prevent duplicate dependencies, I have to fix the versions inpackages/components/package.json to the same exact ones inapps/nextjs/package.json. If I don't do this, then my lockfile will reflect an additional dependency.

I was hoping this would result in no changes to my lockfile, but it seems it does:

{"name":"@repo/components","version":"0.0.0","main":"index.ts","devDependencies": {"moti":"*",  }}

For example,moti now has0.16.1 released. Originally,apps/nextjs had version0.16.0. But now that I added it to@repo/components, I now have both versions installed:

I can put versions there explicitly instead to avoid duplication, but it makes updating a dependency a bit of a hassle. I now have to increment the version in 15+ folders each time I want to update.

I know this is intended, but I figured it would be useful to share the downside. Thanks again!

I think package/workspace managers have tools for doing these kind of bulk install operations. I also think that if you’re not publishing these packages individually, but rather the monorepo structure is just for code organization, there’s no great downside to putting common dependencies in the root package.json. And if youare publishing each package individually, then I think itis an antipattern to import transitive dependencies. There are people who vehemently disagree with me on that point in#38768, but I’m pretty firm on it.

I also think that if you’re not publishing these packages individually, but rather the monorepo structure is just for code organization, there’s no great downside to putting common dependencies in the root package.json.

Interesting, good to know. I'm only concerned for the times that I'm using this to organize shared packages across our internal apps. When it comes to open source monorepos I publish, I do in fact copy over the dependencies in each package. But for an app with code organization, I don't know why importing transitive dependencies would really be an issue. I suppose I'll just put the deps in the root package.json, and hopefully that works fine across the apps themselves.

I think package/workspace managers have tools for doing these kind of bulk install operations.

Maybe lerna does this, I've only used it for publishable packages so I'm not sure. If there aren't downsides to using the root package on internal projects, I might just do that. But yarn workspaces warns against it whenever you install something in the root package, so I figured it wasn't a good pattern.

In case anyone else lands, here, I found a nice monorepo tool that extends Lerna's capabilities to keep versions tied together between packages when you install/upgrade:https://www.npmjs.com/package/lerna-update-wizard

Heard throughlerna/lerna#2142 (comment)

I wrote up a guide here:https://github.com/nandorojo/ts-monorepo-autoimport-guide