AFAIK when you're compiling api project and you import files from analytics project, what happens is:
ts compiler picks up settings from api project
picks files from wherever you references them
smashes them into one program
If files from analytics aren't compatible with the typescript version and options from api, it will break. This is because they are treated as loose files, not independent codebases. And you can't have two different rulesets apply to different files (AFAIK - if someone knows different, I'd be happy to learn).
In this use case, I'd pull analytics out of the monorepo and put it into its own project. Publish as a private npm module. Then reference compiled code from monorepo.
Jon is a self-taught programmer, started in video games but now does web development. He follows principles, argues for scientific software development, and does not like writing in the 3rd person.
So "can't have two different rulesets apply to different files" applies to all settings? Wow, yikes. I got some work ahead of me then. I very much want to avoid pulling anything out of the monorepo.
I've feared from the start that I have to explore building all the code and only rely on js references, so api would use analytics's compiled js output. I'm confident that'll work, but I don't know a way to make that a good coding experience because changes won't be reflected live… 😕
There is one thing you can experiment with that I use in one project. You can declare a local npm module, that lives in the same monorepo with the rest of the code.
Then in lib/analytics define a package.json and tsconfig with the settings you like. Build.
Then when you do import x from 'analytics'; is should find the compiled code from libs/analytics/dist. Then add npm hooks to run compilation on post npm-install or whenever you need depending on your workflow.
I haven't tried this, but maybe it's worth a shot.
Jon is a self-taught programmer, started in video games but now does web development. He follows principles, argues for scientific software development, and does not like writing in the 3rd person.
Yeah that makes sense. It's the "npm hooks to run compilation" that bothers me, because it sounds a lot like I'll be fighting the tools to do things they weren't meant for. But it might be the only way 😬
Thanks for the insights.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Understood.
AFAIK when you're compiling
apiproject and you import files fromanalyticsproject, what happens is:apiprojectIf files from
analyticsaren't compatible with the typescript version and options fromapi, it will break. This is because they are treated as loose files, not independent codebases. And you can't have two different rulesets apply to different files (AFAIK - if someone knows different, I'd be happy to learn).In this use case, I'd pull
analyticsout of the monorepo and put it into its own project. Publish as a private npm module. Then reference compiled code from monorepo.That's really good information, thanks!
So "can't have two different rulesets apply to different files" applies to all settings? Wow, yikes. I got some work ahead of me then. I very much want to avoid pulling anything out of the monorepo.
I've feared from the start that I have to explore building all the code and only rely on js references, so
apiwould useanalytics's compiled js output. I'm confident that'll work, but I don't know a way to make that a good coding experience because changes won't be reflected live… 😕Once again, AFAIK.
There is one thing you can experiment with that I use in one project. You can declare a local npm module, that lives in the same monorepo with the rest of the code.
The declaration would look like this:
Then in
lib/analyticsdefine apackage.jsonandtsconfigwith the settings you like. Build.Then when you do
import x from 'analytics';is should find the compiled code fromlibs/analytics/dist. Then add npm hooks to run compilation on post npm-install or whenever you need depending on your workflow.I haven't tried this, but maybe it's worth a shot.
Yeah that makes sense. It's the "npm hooks to run compilation" that bothers me, because it sounds a lot like I'll be fighting the tools to do things they weren't meant for. But it might be the only way 😬
Thanks for the insights.