I'm new in node world and I'm in facing with a problem,
Currently I'd made a split in the project (in ts) where I work in two new packages(using ts also), to be shared between applications.
All this code are in the same repo, popularly called "monorepo". Below I'll illustrate how this are joined.
But even using the npm link when we made the transpile, from this ts to js these code wasn't included in the final build, to solve this I created two npm packages.
Therefore, apparently this have been adding more complexity into development, because when we need change something in these packages, we need do a link between these package and the project and then if we made some new modification in the packages, it's needed run the npm build in these packages to update the source to be used, because I import the package transpiled (I have some issues regarding the es6 and your imports, node don't accepted it).
I would like how can I improve this method to be less bureaucratic and more effective.
To illustrate my current situation:
/Repo
|_ _/my-app
| |_ _/node_modules
| | |_ _/package-A (npm package)
| | |_ _/package-B (npm package)
|_ _/package-A
|_ _/package-B
|_ _/others-apps
Related
The situation:
client and server both share a folder shared
when we change shared in our development flow, we want the corresponding references to change in customer and server
server works because somehow with npm it seems to work, shared and server use npm
customer doesn't work and uses yarn
mixed typescript and js project
Code Structure:
root/
|- client/
|- package.json
|- src/
|- ...
|- server/
|- package.json
|- src/
|- ...
|- shared/
|- package.json // we don't want to change version every change
|- src/
|- ...
What's been tried
3 solutions proposed here
create a folder common under root and just require the files you need from your files. But you could end up with "long" require such as require("../../../../../common/file")
long require doesn't work with resolution with webpack - and isn't a nice solution
use module-alias to avoid that problem: https://github.com/ilearnio/module-alias
module-alias seems to be the same solution as the next one, in how it behaves.
you could make common a local module (using file:) and install it in package.json https://docs.npmjs.com/files/package.json#local-paths
we currently do this, but we still have to reinstall the shared folder on a change, we currently use yarn upgrade shared which takes a long time and still requires us to know when we need to run it.
in addition we've attempted to get yarn link working but doesn't seem to link properly
we've attempted to use a post-pull hook with husky to run yarn upgrade shared but it's too slow to run every pull especially since it's not needed often
we've considered a true mono-repo 'package' like Lerna but still don't think that it's necessary for the cost to migrate
link-module-alias to sym link folders on post install script, but this fails with typescript files
Goal
either
find a way to automatically sync these in dev environement
find a solution that installs/updates manually - but is fast and can be run on every pull
find a way to automate running yarn upgrade shared that runs (roughly) only when needed not all the time
I guess we could find a way to automate the version increment on any change of shared's version key, and then it's tracked, we could run yarn install and that work work.
The find solution was that we were using React-Native and therefore the normal steps for syncing would work for the IDE but not the React-Native app.
Here is a great article describing how to get metro bundler working with it - however for Typescript we added it to the TSConfig and for the IDE we still needed to add it to our package using the file:../shared directive.
I would like to use a parent NPM package from inside a subfolder, as part of the development process. Let's call my library "logary".
Structure:
.
|- package.json
|- tsconfig.json
|- src
|- ... all the source code
|- dist
|- ... compiled TS as .js, .js.map and .d.ts
|- examples
|- with-nextjs
|- package.json
|- tsconfig.json
The library is written in TypeScript and so is the example. The parent compiles with outDir: ./dist in tsconfig.json. I have multiple entry points (one for the main lib, one for each peer dependency as for example: import withLogary from 'logary/plugins/nextjs'.
I would like to be able to write import Logary from 'logary'; inside ./examples/with-nextjs and have Logary, the constructor, have types attached to it be fully "resolvable" by the TypeScript compiler. I want changes in . to be reflected when ./examples/with-nextjs is reloaded.
It's not a monorepo (in the common sense). I've tried yarn link in . and then yarn link logary inside ./examples/with-nextjs, which doesn't seem to solve it (cannot import module). Furthermore, as I have bumped the version in . to 6.0.0, as I yarn install inside ./examples/with-nextjs, yarn complains that version is not published to npmjs.com and asks me to select a previous version, which it then downloads.
I know there's Lerna ("Splitting up large codebases into separate independently versioned packages is extremely useful for code sharing." — this is a tiny code-base and only has a single package, I just want to reference it in a single direction from an example) and Yarn Workspaces ("It allows you to setup multiple packages in such a way that you only need to run yarn install once to install all of them in a single pass." — which is not my aim)
I'm not interested in adding any special config (like paths) to tsconfig.json in ./examples/with-nextjs because then it's not just to copy the example to as your own app.
➡ How do I best structure a TypeScript library project with multiple peer dependencies and with an examples folder?
Maybe related?
Use yarn workspaces and typescript's project references to reference another package subdirectory — use exports in package.json to solve the logary/plugins/nextjs problem (I'm happy doing that, but I can't get the parent project properly linked with peers correctly installed, so just import Logary from 'logary' in the examples uses the old published version, despite me having run yarn link)
Peer Dependencies In A Monorepo — this is probably a good solution to the peer dependencies problem (e.g. with https://www.npmjs.com/package/rollup-plugin-peer-deps-external)
Using Lerna with unpublished packages — has a similar question, but doesn't ask about consume-only app packages like my with-nextjs. Also, my root is at . not at packages/logary; but maybe I must conform?
Using composite: true in tsconfig.json in . and also references in the child project's tsconfig.json changes how the outDir works; it adds the src/ folder as prefix to all output paths, which is not what I want
Maybe I am totally off track here and I am chasing the wrong Idea:
I have node.js project which contains an npm module (let's call it my_npm_module) which I am also working on.
The module's directory is symlinked into my project like this:
/home
|
|__ myproject
| |
| |__ node_modules
| |__ some_other_module
| |__ my_npm_module (should only get installed/updated in production mode)
| |__ my_npm_module (symlinked only in development mode from /home/modules/mymodule)
|
|__modules
|__ my_npm_module (symlinked to /home/myproject/node_modules/mymodule)
Now, when I call npm install/update in development mode I don't want mymodule to get installed/updated, since I want to use the symlinked version.
But I want mymodule to get installed/updated in production mode. And only in production (NODE_ENV=production) mode.
Since package.json "dependencies" installs/updates for either mode i.e. development and production and "devDependencies" installs/updates for development mode only, I am kind of stuck here.
What I am looking for is something like "productionDependencies" or at least a solution which covers this situation.
Sorry, there is no way to do that.
What you could do is add an extra line when you deploy.
$ npm install my_module
$ NODE_ENV=production npm install
And when you finish with your module development ( let's say you don't want to link it anymore, because it's ready for production ), you just remove that extra line and add it to your dependencies.
Another idea is to modify your package.json file for production in your deploy script. This will ensure that the module will be installed only for production.
I'd like to have my project using the following structure :
|_ bin
|_ docs
|_ logs
|_ src
|_main
|_ api
|_ config
|_ views
...
app.js
|_test
|_ node_modules
|_ package.json
By default, the app.js is in the same directory as the npm modules, is it possible to do it my way? I modified the .sailsrc file to change the paths (especially for the adapters), but once I try to run the app, the sails module can't be found.
I'd like to have my project using the following structure
is it possible to do it my way?
No.
The solution is to to build your sails.js app the same way as the thousands of other sails.js applications. If you don't want to follow convention, you're on your own.
When pointing to a different location of a package my app needs, I can usually just replace the version with "depName": "githubUser/repoName" and it works great.
But what should I do if the package I need to customize is itself a node module of some other package? e.g.
myapp
|_
express.js
|_
send.js
I prefer to avoid publishing a fork of the first package, express in this example, just to use a modified version of send.