Skip to content
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

Multi-app Monorepo Followup #477

Open
mysterycommand opened this issue Oct 15, 2021 · 1 comment
Open

Multi-app Monorepo Followup #477

mysterycommand opened this issue Oct 15, 2021 · 1 comment

Comments

@mysterycommand
Copy link

mysterycommand commented Oct 15, 2021

Bringing this over from npm/feedback#582 per @MylesBorins direction (also, hi Myles!)


Following up on #463 and #470 (and the meeting notes here) … I'm a little unclear on the status of what's left to do here. I'm willing to help if I can!

There were a few action items created as part of that meeting:

Actions:

  • land npm-packlist in cli (@wraithgar)
  • RFC about running prepare scripts for linked bundled deps
  • RFC about workspace layout (@ljharb)

Taking the second action item first, is that something I should take on? I think it might be blocked by the first item on the list because right now the suggested workaround (below) isn't working with npm@8 or npm@7 … yet?

{
  "name": "lambda-a",
  "dependencies": {
    "b": "file:../b"
  },
  "bundleDependencies": [
    "b"
  ],
  "scripts": {
    "prepare": "cd ../b; npm run prepare"
  }
}

Is there any eta on landing npm-packlist in the cli? I've created a demo repo here to test out the workaround and see if I could come up with a "hacky" implementation of running prepare scripts on local bundled deps, but currently when I run npm pack --dry-run --json -w apps/app-a in that repo, I get this output:

[
  {
    "id": "@multi-app-monorepo/app-a@1.0.0",
    "name": "@multi-app-monorepo/app-a",
    "version": "1.0.0",
    "size": 500,
    "unpackedSize": 838,
    "shasum": "4bd38bbbcc89e412082d48ef45849e53a3512f92",
    "integrity": "sha512-+sHhXSMqS8BCZjuirZwAs2rgs1UU2O+mr+nGlBYSQadIWV9nSNA8NAhO6QW2IUYS6XM5TT5+uSQ2k03Y7+FaWg==",
    "filename": "@multi-app-monorepo/app-a-1.0.0.tgz",
    "files": [
      {
        "path": "index.js",
        "size": 133,
        "mode": 420
      },
      {
        "path": "package.json",
        "size": 705,
        "mode": 420
      }
    ],
    "entryCount": 2,
    "bundled": []
  }
]

I'd expect the package.json and index.js from pkgs/pkg-c to show up in the packed output of app-a (maybe under that "bundled" key?) … indeed I believe this is the point of the npm-packlist action item. Just wanting to make sure I'm not missing something.

cc/ @isaacs who offered the workaround at the meeting and might have some ideas? 🤞

@mysterycommand
Copy link
Author

mysterycommand commented Oct 15, 2021

I see that npm-packlist@3.0.0 landed in npm@8.1.0, but my in my repro repo (mysterycommand/multi-app-monorepo) I get the same result running either of npm pack -w apps/app-a from the root, or simply npm pack after cd apps/app-a

That is:

npm notice 
npm notice 📦  @multi-app-monorepo/app-a@1.0.0
npm notice === Tarball Contents === 
npm notice 133B index.js    
npm notice 705B package.json
npm notice === Tarball Details === 
npm notice name:          @multi-app-monorepo/app-a               
npm notice version:       1.0.0                                   
npm notice filename:      @multi-app-monorepo/app-a-1.0.0.tgz     
npm notice package size:  500 B                                   
npm notice unpacked size: 838 B                                   
npm notice shasum:        4bd38bbbcc89e412082d48ef45849e53a3512f92
npm notice integrity:     sha512-+sHhXSMqS8BCZ[...]SQ2k03Y7+FaWg==
npm notice total files:   2                                       
npm notice 
multi-app-monorepo-app-a-1.0.0.tgz

That last line (multi-app-monorepo-app-a-1.0.0.tgz) appears to be the result of app a's prepare script which is cd ../../pkgs/pkg-c ; npm run prepare where pkg c's prepare script is echo ${npm_package_name} … which I guess now that I type it out makes sense. That environment variable must be set for the script of the "current" package, not the package in the current working directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants