-
-
Notifications
You must be signed in to change notification settings - Fork 38
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
Bug With Symlinked Packages in Monorepo #213
Comments
Hey @zaripych, is it expected that in your test case you're restricting the list of files that might be referenced in the sub-project is the only |
Hey @timocov I understand that it's quite unusual that the imported code is uncompiled TypeScript. The monorepo setup I'm experimenting with is to allow development (not runtime when the package is already published and installed as dependency) without having to compile anything at all and without having to wait for those bundles to be generated/created. Imagine a complex project with multitude of packages in a single repo - each of which is TypeScript that needs to be bundled before it can be used - this is quite a headache. When developers just use However, when the code bundled and released - those Running TypeScript is now possible with tools like E.g. if I have following dependency tree: Does this make sense? |
E.g. I do the same with |
Just to clarify, I've added If we revert the proposed change - the non-symlinked test case still works, while symlinked test case stops working. Trying to highlight that this is not about whether I transpile things or not, but about the symlink. We are getting |
Btw, did you try to disable
I'd use composite projects in this case and make a relation between projects explicitly. But yeah, in this case you have to compile a dependency project to make it work. Your current approach looks a bit hacky tbh, because for example the compiler won't compile the dependencies from node_modules simply because it doesn't know where to output the generated files from node_modules.
I didn't dig into this, but basically if you won't compile a dependency and keep ts files as in in node_modules it might not work, because as I said the compiler doesn't generate output for files from node_modules. But I'd look at |
Thank you for bearing with me. Appreciate your time.
I will try it and let you know what this does 👍. Would the bundler be able to inline my subpackage though. Will see.
I considered that. Composites are configuration bloat from my perspective. Package.json is enough. And it worked so far - surprisingly 😀 Just trying to keep it DRY.
I've had experience with monorepo setups with TypeScript before composites were a thing and people would use So, I'm not interested much in what
This already works. Worked on multiple projects for me. It's just I never got to fixing declarations for inlined packages. |
Have you tried to publish a package that consists of ts files only (without prior compilation/transpilation) and build an app that depends on this project? I'd like to see how it works 🙂 This is basically what I see when you say that "I link other packages in |
Sorry I still haven't got to trying. 👍 Will do this evening.
If by publishing you mean to However, at some point I did consider not to bother and generate declarations and just include source code along with bundled js to save time on declarations generation. |
@timocov the config didn't help, and it prevented from other npm packages mounted by {
"compilationOptions": {
"preferredConfigPath": "./tsconfig.json",
"followSymlinks": false
},
"entries": [
{ "filePath": "src/index.ts", "outFile": "dist/dist/main.es.d.ts" },
{ "filePath": "lint.ts", "outFile": "dist/dist/lint.es.d.ts" }
]
}
Error: Cannot find symbol for node: Plugin But with this it works 👍 {
"compilationOptions": {
"preferredConfigPath": "./tsconfig.json",
"followSymlinks": true
},
"entries": [
{ "filePath": "src/index.ts", "outFile": "dist/dist/main.es.d.ts" },
{ "filePath": "lint.ts", "outFile": "dist/dist/lint.es.d.ts" }
]
} The Basically the |
UPD: I've tried I wonder if these somewhat naive code changes I've made (that basically make Then I could just generate project references automatically from |
@timocov if we agree on a solution that would allow users to generate bundles via single command, whether it is explicit Currently I see the solution somewhat like this:
Thoughts on this solution:
|
@zaripych sorry for late reply. After reading this thread again I think that I'm not going to implement compiling files from the But the good news, it looks like the issue might be related to the way how the linking of packages via Is it possible for you to create a repro for your issue (with Below some replies to your messages and questions.
For supporting composite projects there is an issue, see #93. But IIRC there were some issues with supporting this, because the compiler's API for composite projects is different it it might not be possible to get the output for everything. Also, there might be a question how to treat your composite parts - as an "externals" or "internals" (but it is possible that I'm messing it up with other tool https://github.com/timocov/ts-transformer-properties-rename).
If you run it against
If you're talking about incremental compilation that the compiler supports this might be tricky. From what I've seen, the compiler doesn't store anything about the compilation besides the deps tree, last modified dates and some other meta information that helps the compiler to say "nothing has changed from the last compilation so nothing to do". But once you change a file, the compiler will compile the project anyway. So from my observations the compiler doesn't store or cache any results in that way. The way how the compilation of composite projects works is that the compiler for a dependency doesn't use On the other side, the tool requires the files to be compiler and type checked because the tool relies on that and this cannot be omitted. |
@timocov No worries and thank you for getting back to me. Appreciate it.
That makes total sense. I already got the vibe, so was trying to solve my problem somehow differently. I would rather not maintain a broken fork myself or let people use it and suffer later. Just to clarify my end goal - is to reduce amount of configuration that we need to do in a monorepo. We don't necessarily need "compiling from
I think I highlighted in the above screenshot in this comment that TypeScript itself treats I'm still not really sure about
As you pointed out - I'm doing it hacky way. I'm using git clone https://github.com/zaripych/repka.git -b dts-bundle-generator-repro
cd repka
npm install -g pnpm@7.5.0
pnpm install
pnpm run turbo run declarations --filter @tooling-tests/todo-list-cli --force Have a look at On the side note - if https://github.com/Swatinem/rollup-plugin-dts/blob/master/src/index.ts#L22 which uses TypeScript native API to parse and load it - but then injects those options in: https://github.com/Swatinem/rollup-plugin-dts/blob/master/src/program.ts#L58 Then I could have just generated aliases (via |
I was able to have a proof of concept working for the approach with specifying Summary of changes:
The API is used like so in my repository: UPD: Obviously the alternative to this is to generate |
@zaripych Apologies for late reply (again 🙁).
Have you looked into #137 ? Were able to find a proper types for the compiler options? I'd like to have compiler options in the options too, but we cannot expose internal interfaces, but public ones aren't provided in the types (at least from my understanding).
Wait, don't you have tsconfigs in your repo committed? What is the main difference between your "normal" tsconfig and the one for dts-bundle-generator? Keeping in mind that you can use
I like this, but the difference is that you are are to write a config file in json file where you don't have an access to typescript module to specify a configuration (
Is there anything changed there? I'm trying to run the commands you've provided but getting the error: $ pnpm run turbo run declarations --filter @tooling-tests/todo-list-cli --force
> @repka-kit/repository@0.0.0-development turbo C:\projects\repka
> turbo "run" "declarations" "--filter" "@tooling-tests/todo-list-cli" "--force"
node:internal/errors:464
ErrorCaptureStackTrace(err);
^
Error: spawn /C:/projects/repka/packages/build-tools/ts/node_modules/.bin/turbo ENOENT
at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
at onErrorNT (node:internal/child_process:477:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -4058,
code: 'ENOENT',
syscall: 'spawn /C:/projects/repka/packages/build-tools/ts/node_modules/.bin/turbo',
path: '/C:/projects/repka/packages/build-tools/ts/node_modules/.bin/turbo',
spawnargs: [
'run',
'declarations',
'--filter',
'@tooling-tests/todo-list-cli',
'--force'
]
}
ELIFECYCLE Command failed with exit code 1. |
No worries. I think I have a good solution - even though I maintain my own fork - the changes are in safe zone of just configuration reading and easy to merge with upstream. No rush at all - would appreciate it if we eventually land with something useable by everyone though 👍
The main difference is that there are no references or It's all good - I can generate the part of
I see what you mean. That means my changes are actually maybe somewhat buggy. But if we also want to allow This means my current code has typing bugs I need to fix ...
This looks like dependencies weren't installed. Maybe because I'm using canary build of |
@timocov on the side note - I don't think it's just |
Because it switches the compiler to another way of working, which is a build mode or know as composite projects (or referenced projects) that aren't supported right now (see #93). |
@timocov Thank you for your time so far! So would you be willing to look at PR for |
@zaripych sorry for late reply. For #137 - if you will find a way to getting the types for compiler options from the compiler's types (so they would be up to date and related to the current compiler's version - that is installed locally) - feel free to share it and create a PR. Otherwise I don't think that it makes sense to have something like As for this ticket, is there anything that left unresolved so far? |
Bug report
I'm using
dts-bundle-generator
in my experimentalmonorepo
. I found it irreplaceable, especially if I bundle in some of mydevDependencies
and they would not exist as packages in published npm package, but their TypeScript declarations need to be inlined. I don't know any other tool that does this. Well done 👍. And thank you 🙏.I use
pnpm
to install packages. So I have following directory structure which describespnpm
behaviour the best:We can see that
packageB
is going to be a symbolic link.When using
dts-bundle-generator
I get a compiler error, saying that I cannot import this or that. Example:Additional context
The test that reproduces this issue is here:
zaripych@49ad3a6
I fixed it by making these changes:
zaripych@794a1a3#diff-5a014ac4d87f713ea8b9c8dd8966ce3b77df4ecc8e263b4baf9b9469bf9f2917
Would it be possible to incorporate these changes in the main repo?
The text was updated successfully, but these errors were encountered: