We Keep Coding

How to package grpc-web generated code into npm package

I have protofiles defined inside a go module and publish this module so servers and go-clients can reference the generated code. Now I also want to have grpc-web client to communicate with the server. grpc-web generates ts and js files, but inorder to use this in browser I need to package this as npm module or copy the generated code into browser repo manually which I do not want to do. What is the standard practice here?
Is there a good solution to package npm & go module from proto files.
Update: I ended up copying over the generated ts/js files into desired location as part of my standard build. Since I have a mono repo this is sufficient right now. Kind of straight forward and also source controlled. Not sure if there is a better idomatic way.

Releasing a Javascript library for client use

I have a Javascript library that I wrote for a client. This is written in typescript using webpack and "compiles" into javascript. I want to give the client access to the distribution files but not the whole source. Ideally they can install from the command line to make installing updates easy.
The library provides some javascript functions. The client would install the script in one location on their server. They could then include the javascripts in their web surveys as they need it.
+project
+dist
-main.js
-vendor.js
-index.html
-README.md
-LICENSE.md
+src
-index.js
-index.html
...
My initial thoughts are to give them access to a private git repository that contains only the distribution files. So my project would be a git repository, only I would have access to this repo. I would then copy the contents of the dist directory to a release directory. The release directory would be another git repo I could supply to the client.
I'm not sure this is the best approach.
It was suggested that GitHub releases may be an option - but I don't use GitHub, I use GitLab and would like to continue to do so.
npm also doesn't seem like a good choice. It installs files into the node_modules directory and creates a package.json file. That's going to be confusing to my client and isn't "clean".

It sounds like a second git repository as submodule could work for you. On your side it would receive the built files, and on the clients side they could consume them.
I'd suggest making use of tags to indicate significant versions in the submodule
By using a separate repository there is no risk of leaking the original files.
Alternatively you could package the files as a zip, and upload somewhere like S3 as part of your ci process, and write a script to give the client that can automatically download the distribution files - but this seems more complex than just using a package manager like npm.

Does a Node.js package.json need to be at the root of the repository?

I have a Node.js package that currently resides in a subdirectory of a GitHub repository. I can currently publish it without setting the repository field, but then my users will get a warning and there is less useful information on the Node Package Repository page than their could be (issues and pull requests links are missing).
If I set the repository field in package.json to point to the parent repository, will that work? Will anything break because the package.json file is not at the root of that repository (npm, in particular)?

If I set the repository field in package.json to point to the parent repository, will that work?
Yes. This field is not used by any critical npm functionality. It's just so if contributors want to clone a repo so they can work on the project.
Will anything break because the package.json file is not at the root of that repository (npm, in particular)?
No. I don't believe anything will break.
You should set the repository field to the parent project's top-level .git path. The purpose of this field is for SCM (git, etc) to be able to clone the project. In your case, the closest thing is the parent project. This should avoid the warning message.
You should set the bugs field to the issues page. This should then show up on the npm web site. I don't think repository and bugs are related directly or any assumptions are made about one based on the other by npm.
If you don't otherwise have a web site for it, you could set homepage to the github URL to the directory containing this npm module within the parent repo. Stick a README.md file there and github will render it below the directory contents.

bower custom build - choose specific files

I am continously encountering the issue, where I need / want to include a specific file from a bower package to my app, and find no easy way to do it. This is not limited to minified versions.
Example: Moment.js comes with about four different files one can choose to include. Those are moment.js, moment.min.js, moment-with-langs.js, moment-with-langs.min.js. The bower.json and the hidden .bower.json files inside the package specify which file should be included during the build in the "main" array (here's an example with sass-bootstrap bower package):
"main": ["./dist/js/bootstrap.js", "./dist/css/bootstrap.css", "./dist/fonts/*"]
But there is no such thing in the apps bower.json file to specify for dependencies. One can only specify the dependency.
There is some discussion on the case: I found two topics on bower's github, namely https://github.com/bower/bower/issues/368 and https://github.com/bower/bower/issues/369 and also here How to configure Grunt to replace Bower dependencies by its minified versions but the issue is not limited to the minified versions.
All the topics end in the same way, stating that bower, as a package manager, should not take care of the custom build process that an app requires. But that leaves the developer with the problem of having to go about bower with the majority of the repos OR minifying the packages on his/her own. There are many who disagree on both.
The way I went about the problem with moment.js is I created a vendor folder and manually added the file that I needed and then added a Grunt task to do it automatically. But it just would be so much easier if there was a standard way of providing users the option to include e.g. all recommeded (default) files, the minified versions or just allow to choose specific files from the app's bower.json dependency list.
Perhaps I am not using it right, or maybe it's not a popular problem. I don't know if it's some feature that should be added to bower, but maybe other devs have experience dealing with the case?

If you use browserify it has debowerify transformation that just grabs the first file from the main array. To include a particular extra file call the require function with appropriate path.

Multiple package.json files in one package

I have a site running on php that uses Node for a few development tasks. Currently, our team relies on puppet to install the node modules that we use for these development tasks, however, I was thinking of moving to using a package.json file in the root of the site instead.
My problem is this:
My php app is actually 3 separate sites that we have mixed into one (1 public facing site, 1 internal site, 1 client facing site) and its a likely scenario that some installations of the app depend on different node packages (or different versions of the same pacakge). While I know it would be nice to split these apps apart and have each one manage its own dependencies, short of this, is there some way to have multiple package.json files in one site?
In other words:
/package.json
/site1/package.json
/site2/package.json
/site3/package.json
Or perhaps, is there a way to have the one package.json handle dependencies for more than one app?
I don't know if this makes sense, let me know if I'm just way out in left field here. Thanks!

As far as I have seen, package.json deals with a single directory's dependencies (and a single instance of node_modules).
Your best bet is to split your applications into separate directories.
Barring that, you could just add all of the dependencies to a single package.json file. It will install into the node_modules folder and any app within that directory will have access to all of the installed modules.