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

Missing "name" and "version" keys in package.json and package-lock.json #1692

Closed
x80486 opened this issue Aug 25, 2018 · 5 comments
Closed

Comments

@x80486
Copy link

x80486 commented Aug 25, 2018

Is there any reason why "name" and "version" keys are missing in package.json – and eventually later on in package-lock.json?

According to Specifics of npm's package.json handling:

If you plan to publish your package, the most important things in your package.json are the name and version fields as they will be required.

@ffflorian
Copy link
Contributor

Yes:

If you plan to publish your package, [...]

We are not publishing this package. So we don't need the fields. 😉

@x80486
Copy link
Author

x80486 commented Aug 28, 2018

Ha! I like it! But...since I'm trying to do a Flatpak for this one, can you put those 😇 — if it's not too much trouble.

@ConorIA
Copy link
Contributor

ConorIA commented Aug 30, 2018

@x80486, I got started with a Flatpak, but couldn't make it work. I did workaround the version and name issue though using build commands. I'm attaching the files I had, perhaps they will be of some minor use to you.

wire flatpak.tar.gz

EDIT: The python script is from here: https://github.com/flatpak/flatpak-builder-tools/tree/master/npm

@x80486
Copy link
Author

x80486 commented Aug 30, 2018

I'm able to move (a little bit) forward with this one. I have the work here, in case you would like to give it a shot if you have some free time.

The Python script generates a generated-sources.json in order for Flatpak to build the artifact later on while being offline. I'm getting this error right now:

> @ preinstall /run/build/wire/main
> cd electron && npm install

npm info it worked if it ends with ok
npm info using npm@5.6.0
npm info using node@v8.11.4
npm info lifecycle wireinternal@~preinstall: wireinternal@
npm ERR! Error while executing:
npm ERR! /usr/bin/git ls-remote -h -t https://github.com/wireapp/node-addressbook.git
npm ERR! 
npm ERR! fatal: unable to access 'https://github.com/wireapp/node-addressbook.git/': Couldn't resolve host 'github.com'
npm ERR! 
npm ERR! exited with error code: 128

It's at first confusing because it looks like I don't have access to GitHub, but in reality is the Flatpak builder that never goes online – I know for sure because I ran into the same problem with another Electron application a few days ago.

Funny thing is, the generated-sources-prod.json that you gave me have that dependency:

    "node-addressbook": {
      "version": "git+https://github.com/wireapp/node-addressbook.git#5799991759e017d92931075c5fd6eed9e66936b9",
      "optional": true,
      "requires": {
        "nan": "2.8.0"
      }
    },

...but the one I'm generating from the .tar.gz (release) file, does not. So you are applying some magic that I don't know 😮 ...I was expecting those files to match 🙅‍♂️

@ConorIA
Copy link
Contributor

ConorIA commented Aug 30, 2018

I haven't looked at this in some weeks. I do recall that the errors I was hitting were missing dependencies, even though I had thought that I had captured them all in the two package-lock.json files. I can't recall any magic in particular, but I think that there is something fishy going on in the sed command at the bottom of the generated-sources file. You seem to be much further ahead of the curve than I was as I fumbled though this. 😟

@x80486 x80486 closed this as completed Oct 10, 2018
tobni pushed a commit to pantsbuild/pants that referenced this issue Jul 11, 2024
…missing (#21159)

Closes #20859.

While this is a simple fix and addresses the linked issue, there is an
interesting edge case to discuss:

Internal packages do not necessarily have a name field in `package.json`
(see wireapp/wire-desktop#1692,
facebook/react#13107 for examples). The
JavaScript backend in Pants does require that each package.json define a
name, but I'm not so sure that's necessarily the right behavior.

It's worth considering whether we should make names optional in Pants,
given that larger JavaScript monorepos may have internal packages that
are not meant to be published. Furthermore, different JS package
managers handle this situation differently -

* [Bun doesn't handle package.json files without a
name](oven-sh/bun#6317)
* [npm assigns the parent directory name as the
name](npm/cli#2264)
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

3 participants