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.
Maybe that code is deep inside the product, maybe it's some hardcoded functions, maybe it's a concept that's been copy-pasted across multiple systems, maybe it lacks tests, whatever the case it's a shared pattern that just needs to be extracted without too much ceremony. It can be improved later, but right now we just want to put a box around it.
What I mean is: I have code I want to improve, but I don't want to or can't prioritize that work right now. The code isn't great, but it's by extracting it I start the process of improving it. To that end I feel it should be possible to run that code with different settings. In this case analytics isn't Typescript strict compatible to represent that kind of code-quality issues that I've seen in the codebases I've worked on.
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.
That's a good question! I try to cover that in Finding the middle ground, specifically with:
What I mean is: I have code I want to improve, but I don't want to or can't prioritize that work right now. The code isn't great, but it's by extracting it I start the process of improving it. To that end I feel it should be possible to run that code with different settings. In this case
analytics
isn't Typescript strict compatible to represent that kind of code-quality issues that I've seen in the codebases I've worked on.Understood.
AFAIK when you're compiling
api
project and you import files fromanalytics
project, what happens is:api
projectIf files from
analytics
aren'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
analytics
out 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
api
would 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/analytics
define apackage.json
andtsconfig
with 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.