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
GitHub installs from npm #60
Comments
Could this be worked around by creating own top-level |
Only if there was dnt on npm which would perform the compilation locally |
Recommend following the config tasks proposal for Deno: denoland/deno#12764
I think this is out of scope for dnt. If you want to let users try something out this way, you could create an empty branch in the git repo then put the output of dnt in there with the feature for them to try. Then users could run the command like you mentioned. Alternatively, a separate tool could be created for node that downloads deno locally if it doesn't exist and then runs a build script that may include dnt. There could be a folder in the repo that people could point their npm clients at that contains a package.json that does all of this in a postinstall script. Then users could install doing something like: # I forget what the proper way of writing this command is, but anyway
npm install https://github.com/username/repo/tree/branchName/folderContainingPackageJson Edit: It's easier to just publish the package as |
This is missing the point. The problem is different. Situation before targeting Deno and backporting via The question is, how could Either way, polluting the git with build output is not a solution that should be the recommended approach. Better than creating a branch and pushing the JS files would be to always commit the The longer I think about it, the less useful is the property of I fail to see how anyone who would build a serious project for Node.js would not want to be in control of their This is confirmed by
This is a better solution than manually pushing build output to GitHub whenever we want people to try something out, but again, this tool does not need to exist if you were just changing |
The point of dnt is to take a deno module and distribute it on npm. There is no need for a package.json in a deno-first module, which is why it's a build artifact. This definitely seems out of scope for dnt because dnt is just a build function—it's not a toolchain and doesn't prescribe how your repo is setup. If you really want a package.json then you can have one and then supply its json data to dnt's build options. Then, with a package.json file you can develop some postinstall scripts that does everything you want for npm users to install it. But again, even without having a package.json in the repo, there are many possible solutions to this problem. For example, it would be trivial to update a GitHub action workflow on the main branch to build using dnt (which it should already be doing for testing purposes) and then push that output to a bare branch (ex.
All of this is completely configurable in dnt and you are in full control of the output of the package.json file. Shimming is completely configurable now and you can provide whatever contents you want to the
You should be writing many
This doesn't sound great to me. In my opinion, it's more ideal to have a deno-first project that looks like a deno-first project and not confuse people by looking like a node project. |
I'm going to close this one as I believe it's out of scope. To summarize:
|
Understood. There are 20+ hybrid repos in our org that target both Deno and Node, and they all have a slightly different setup. However, the suggestions do not satisfy as solutions to any of these projects. Hence, I conclude that Thank you for your elaborations! |
What would it take to publish |
Alternatively, could |
Consider mentioning |
I prefer to develop code for Deno and with Deno tooling, but more than 90 % of my users are consuming my library from npm. (I'm currently using deno2node.) I was looking into what a migration to dnt would mean. Since #57 I'm pretty sure the module would work perfectly on Node once I get the config right.
However, it is a priority that Node users aren't second-class citizens. I don't want to have a much worse npm package in terms of tooling for my users, just because I'm natively targeting Deno. Here are a number of things that I believe to be worse when using dnt with all its magic to generate configuration files.
Currently, apart from actual development, the npm package looks perfectly like it's native Node stuff. A lot of things would turn into magic from a Node point of view with a migration:
package.json
in repo, so it doesn't look like a repo that contains code which would run on Node.tsconfig.json
filedeno fmt --config deno.json
, so people would still need to have the CLI installed, but npm scripts often serve as landmarks to tell people how the repo works. If I'd use dnt, they'd need to know what Deno is, how to invoke the CLI of Deno with all the commands, and need to know the--config
option.Basically, dnt may make the build output look like a Node module, but from a development point of view, people would have to have a fair bit of knowledge about Deno.
For example, when people report a bug or request a feature, we'll implement it on a feature branch. We can now tell them to install the feature branch into their
node_modules
folder to try out if that's what they expected. They just need to runnpm install grammyjs/grammY#feature-branch
and they're good to go. Once they confirm, we can merge and everything's well tested. It would not be feasible to have themjust to try out a small fix.
Do you have any ideas how to tackle these problems?
The text was updated successfully, but these errors were encountered: