chore: remove package.json from private app project #32
Conversation
While testing out a new project this past week, and trying to emulate some of the patterns I've seen in customer extensions, I found a couple issues: - `post-install` script assumes npm as package manager, which means it will automatically generate package-lock.json files in two directories - `post-install` and `build` scripts aren't resilient when project structure changes. After removing the `app.functions` directory (I have no serverless functions), that led to the CLI hanging and giving me an obscure error message when it failed These scripts served their purpose as a crutch to get around friction points (having to jump around to different directories to run commands & manage packages) but at this point it seems less helpful and would be a net negative if customers hit the edge cases. Perhaps we're covering up issues by including them here, as well.
banderson
requested review from
brandenrodgers,
joe-yeager,
robrown-hubspot,
sejal27 and
aanchalHS
|
Should we apply these changes to both the public and private apps? |
| @@ -1,11 +1,7 @@ | |||
| { | |||
There was a problem hiding this comment.
I wonder if it would it be beneficial to remove this file entirely? Running npm install at the wrong directory level seemed to be a pretty common support issue, and the post install was mitigating this in at least some of the cases. Are there benefits to keeping this file around without the scripts block?
There was a problem hiding this comment.
I could not agree more, @joe-yeager! I took a baby step to remove the fangs from this issue with this small change, but I am also happy if we go all the way and remove it!
|
@joe-yeager @brandenrodgers I totally forgot that npm will still handle
|
|
This is the test flow, and this change works, as in no package.json's anymore. You can see the surprise moment at the end where |
banderson
changed the title
Edit (2024-08-16):
After talking this over with the team and experiencing additional support issues related to root-level package.json, we all think it's probably best to remove the whole file at this point (25d1e4a). So the details below are still accurate, but some the details don't matter as much.
I was able to scaffold a new private app without generating package.json files, and upload the newly generated project, and it all worked end-to-end:
Aside: I was surprised to see the warning in the CLI about missing package.lock files. I'm not touching that here, but maybe someone else can take a look at that piece? ¯\_(ツ)_/¯
While testing out a new project this past week, and trying to emulate some of the patterns I've seen in customer extensions (namely, devs using yarn or pnpm package managers over npm), I found a couple issues:
postinstallscript assumes npm as package manager, which means it will automatically generatepackage-lock.jsonfiles in several directories, leading to warnings from other package manager CLIs and tooling.postinstallscript isn't resilient to project structure changes. After removing theapp.functionsdirectory (I have no serverless functions), that led to the CLI hanging for a long time, and eventually giving me an obscure error message when it failed. I don't have exact repro steps for the error message I saw the first time, but it still hangs for about a minute:These scripts served their purpose as a crutch to get around friction points (having to jump around to different directories to run commands & manage packages) but at this point it seems less helpful and would be a net negative if customers hit the edge cases. Perhaps we're covering up issues by including them here, as well.
Minor changes:
I also added
private: trueto make sure it doesn't get accidentally published, and removed thenamefield, as this has become just one more thing for me to remember to change or delete after scaffolding a project. It should not be required unless publishing to public repository.