node.js - Hur ställer jag in min inbyggda node-modul om den importeras av mitt värdprojekt?
Jag utvecklar 2 projekt i TypeScript. Först, en native node-modul kallad my-node-module. Den importeras av mitt värdprojekt kallat host-project.
package.json av host-project
"my-node-module": "git+ssh://[email :foo/my-node-module"
my-node-module är skrivet i TypeScript. Jag vill importera det inom mitt värdprojekt.
Fråga 1
Huvudingången i package.json för my-node-module är js/index.js. Denna fil skapas om jag kör npm run tsc i roten av my-node-module.
Kan jag direkt importera projektfilen (src/index.ts) via import myModule från 'my-node-module' eller är transpileringssteget verkligen nödvändigt?
Fråga 2
Om frågan ovan besvaras med ja, hur skulle jag säkerställa att npm i på värdprojektet också kör de nödvändiga transpileringsstegen för mitt beroendemodul my-node-module?
Svar #1
Jag använder en liknande metod i ett av mina kommersiella projekt. Jag har viss gemensam kod som används av alla,
- React JS frontend
- React Native frontend
- Express js-baserad GraphQL-server
Sedan finns det ett annat paket som har UI-komponenter redo att importeras i React JS-webb och React Native-mobilprojekt.
Alla dessa projekt installeras som npm-paket och är hostade i fjärr-git-repositorier (i mitt fall är de på fjärr-Bitbucket-repositorier)
Till exempel har jag följande konfiguration för mitt projekt med delad logik.
paket @myorg/common-logics
{
"name": "@myorg/common-logics",
"version": "1.4.0",
"main": "./build/index.js",
"types": "./build/index.d.ts",
"private": true,
"files": [
"build/**/*"
],
"author": "Dilshan",
"license": "MIT",
"scripts": {
"clean": "rimraf build",
"build": "yarn run clean && tsc",
"test": "npx ts-node src/test/data.ts",
"version-upgrade": "yarn version patch",
"changelog": "standard-version"
},
"devDependencies": {
"@types/lodash": "^4.14.177",
"@types/uuid": "^8.3.3",
"rimraf": "^3.0.2",
"standard-version": "^9.3.2",
"ts-node": "^10.4.0",
"typescript": "^4.5.2"
},
"dependencies": {
},
"repository": {}
Tidigare byggde jag manuellt detta projekt genom att köra yarn build eftersom jag var den enda som arbetade med detta delade paket. Du kan också använda Husky eller en pipeline.
Om jag var tvungen att trycka detta till ett npm-register, skulle jag ha byggt koden i en pipeline.
Detta fungerade tills jag var tvungen att hantera flera npm-paket. Det blev svårare att hålla reda på alla, så här använde jag https://nx.dev/ för att hantera alla mina npm-paket. Sedan skapade jag separata repor (eftersom jag inte använde ett NPM-register) bara för att hålla byggkoden för varje paket i NX monorepo.
Så allt jag gör är att utveckla i NX mono repo och sedan pusha det till repositoryt. Sedan bygger jag i en pipeline biblioteken i NX-projektet och pusha dem till de skrivskyddade repositoryerna som bara håller den senaste byggda koden från källkoden.
Jag kan säga att det fungerar och för närvarande använder produktionssystemet dessa delade bibliotek och jag har arbetat med dessa anpassade delade bibliotek i över 6-7 månader nu. Jag har aldrig haft några problem förutom detta ena problem med NX. Jag har heller aldrig haft någon synkroniseringsproblem mellan källkod och byggkod hittills.
Om du inte kan sätta upp CI/CD-pipelines, antar jag att du kan göra samma sak på din lokala dator med Husky och anpassat shell-skript för att bygga och kopiera byggkoden till skrivskyddade repos.
Svar #2
Jag använder normalt ett SharedModule för att använda vanliga moduler över flera projekt.
du kan skapa ett delat modul som har alla dessa moduler och komponenter. Importera dem till ett delat modul och importera detta delade modul till alla funktionsmoduler. Detta kommer att spara importer och många kodrader.
import { CommonModule } from '@angular/common';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { CustomerComponent } from './customer.component';
import { NewItemDirective } from './new-item.directive';
import { OrdersPipe } from './orders.pipe';
@NgModule({
imports: [ CommonModule ],
declarations: [ CustomerComponent, NewItemDirective, OrdersPipe ],
exports: [ CustomerComponent, NewItemDirective, OrdersPipe,
CommonModule, FormsModule ]
})
export class SharedModule { }
Observera följande:
- Den importerar
CommonModuleeftersom modulens komponent behöver vanliga direktiv - Det deklarerar och exporterar hjälprör-, direktiv- och komponentklasserna
- Den återexporterar
CommonModuleochFormsModule
Genom att re-exportera CommonModule och FormsModule, får alla andra moduler som importerar detta SharedModule tillgång till direktiv som NgIf och NgFor från CommonModule och kan binda till komponentegenskaper med [(ngModel)], ett direktiv i FormsModule.
Även om komponenterna som deklareras av SharedModule kanske inte binder med [(ngModel)] och det kanske inte finns något behov av att SharedModule importerar FormsModule, kan SharedModule fortfarande exportera FormsModule utan att lista det bland sina importer. På detta sätt kan du ge andra moduler tillgång till FormsModule utan att behöva importera det direkt i @NgModule-deklarationen.
