I'm looking for a typescript definition file for the abstractions that are defined within the library ng-i18next (i18next for angularjs).
Looking through the project's page I didn't find anything. And when I go to issues -> ask, I landed here at SO.
I can't find it there neither using npm install ng-i18next plus exploring the file system with the downloaded files.
So basically no luck disregarding the "interface" used for searching a typescript definition file. Perhaps it doesn't exists.
Via web-gui
Via local-cli
Any data about the whereabout of this file will be appreciated.
Answer: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/ng-i18next/index.d.ts
Research: The repository https://github.com/i18next/ng-i18next has a link for typings, and it redirects to https://www.npmjs.com/package/typings, a deprecated repository that used to store typings, and it says in it's readme.md the following message:
Starting from TypeScript 2.0, users can install typings using npm install #types/<package>. These typings are coming from DefinitelyTyped.
So, in that repository (https://github.com/DefinitelyTyped/DefinitelyTyped) if you look for ng-i18next, it appears, nevertheless, its interface is just has options: any, so it doesn't give you any help.
Related
I am getting rid of lodash, so some stuff I am redoing in es6 and other like this one I would like to keep but just this one function.
I see there is this npm https://www.npmjs.com/package/lodash.minby but im not sure if i install this it will only install this, or the whole library, can anyone please confirm?
Thanks.
From the documentation:
The lodash method _.minBy exported as a Node.js module.
So, yes, it just installs this specific function from lodash
Yes, if you install lodash.minby, at the time of this writing, you will get version 4.6.0 which contains a package.json file, a README.md file, a LICENSE file, and an index.js file. It has no other dependencies, so that is all you will get. The index.js file is over 2000 lines long, but that's what it takes apparently to implement the functionality.
In contrast, at the time of this writing, npm install lodash will give you version 4.17.21 which contains over 44000 lines of JavaScript spread out across many files. So that's about 22 times as large.
I have a NPM package with a small user base, yesterday I created a new version and wanted to release it. I thought that I might as well make use of the new GitHub Packages and so I setup everything as GitHub suggested and released!
Now the problem is that I still have the old NPM page running on version 2.0.2 while everyone currently uses this as their dependency while the new GitHub package is on 2.0.4, Is there a way to 'synchronize' these two. Of course the GitHub Packages uses the <USER>/<PACKAGE> labeling while NPM just uses <NAME>.
Is the only thing I can do to publish on GitHub Packages and on NPM and just try to move users away from the NPM page?
If your publishing a public package, your better off just publishing it on NPM, as that is what most developers are used to.
I use GitHub Packages at work and the only advantage is that is effective free for hosting internal packages, as we are already paying for GitHub anyway. If it wasn’t for the zero price we wouldn’t be using it.
If you really want to force all your users to migrate to GitHub packages, and have to set up npm to work with it you could mark you old version npm deprecated and use that to point people to the new version.
https://docs.npmjs.com/cli/v6/commands/npm-deprecate
Here is another solution, but there is a catch.
Change your registry.npmjs.org package content to
index.js
export * from '#schotsl/my-package';
Now your registry.npmjs.org package is (almost) pointing to your npm.pkg.github.com package.
Only almost because any development directory for a project downstream of registry.npmjs.org/my-package, must configure the scope-to-server mapping for #schotsl/my-package to npm.pkg.github.com in a package manager config file.
In the case of package managers 'npm' and 'yarn' (v1) that can be done in
an .npmrc file at the same level as package.json.
The required .npmrc content is
#schotsl:registry=https://npm.pkg.github.com
# Github PAT token, packages:read authorization only ok
//npm.pkg.github.co/:_authToken="ghp_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
The first line is the scope to server mapping.
The second line is a Github personal authorization token (PAT) with at least package:read permission. It is actually pretty liberal. A PAT with package:read issued from any github account will allow read access to every github accounts packages.
For the 'yarn' v2 package, the .npmrc file does not work, and instead a couple of keys need to be set in .yarnrc.yml.
Unfortunately there is no way to set the scope-to-server mapping and the token inside the registry.npmjs.org/my-package package itself.
Putting the .npmrc file in there doesn't work, it is ignored. And that wouldn't be a good solution anyway, because not all package managers read .npmrc files.
That is the 'catch' - using npm.pkg.github.com packages requires package manager specific config settings to be made by every downstream developer.
In addition, what if two different upstream packages have colliding scope names, each mapping to a different server? The current config methodology fails in that case.
Feature Proposal not current behavior
Ideally, there would be a common interface agreed upon by all package managers inside package.json - and the scope-to-server mapping would be defined in the package that directly references the scope. For example, in the package.json of my-package on registry.npmjs.org
{
dependencies:{
"#schotsl/my-package":"1.0.0"
},
registries:{
"#schotsl/my-package":"https://npm.pkg.github.com",
},
auths:{
"https://npm.pkg.github.com":"ghp_XXXXXXXXXXXXXXXX",
},
}
Then downstream users would not need to config for each scope, and predictable (and risky) problems with scope name or package name collisions would not occur.
But that is not the way it is. Therefore Github Packages (npm.pkg.github.com) doesn't really seem to be a feasible way to provide public packages which may become dependencies of other public packages. No problem for private packages though.
I've created a web app template that I use frequently for many different projects.
I would like to create an NPM package for it so that it's easier to install for new projects, separate the template from the project files, separate the template dependencies from the project dependencies, and allow easier updating of the template across all projects.
The issue I have is that I need some files/folders to be installed in the root directory (i.e. where package.json is saved). Most can go in the node_modules folder however I have some files that must be placed in the root directory.
For example, the template uses Next.js with a custom _app.js file. This must be in the root directory in a folder named pages. I also have various config files that must be in the root directory.
Can this be done with NPM, or does everything need to be installed in the node_modules folder? I'm having trouble finding anything on SO or Google that answers this, so if you happen to know a guide online on how to do this or can outline things I should search for it would be much appreciated.
With pure npm, everything has to go to the node_modules folder, so you can't solve your issue this way.
Maybe going with a templating tool such as grunt init or yeoman could be a solution here, although – unfortunately – you'll then lose some of the benefits of being able to install a package via npm.
Another option might be to use GitHub template repositories, which have just been introduced recently.
Last but not least one option might also be to just have the files' contents in the npm package, but create the pages/_app.js manually, but inside of it simply require the file contents from an npm module, and that's it. This at least helps to have the content portable, but of course it still asks you to setup the file and folder structure on your own.
Sorry that I don't have a better answer, but I hope it helps anyway.
PS: One "solution" might also be to use the postinstall step in an npm module's package.json file to create folder structure, copy files to where they should be and so on, but at least to me this feels more like a clumsy workaround than like a real solution.
In Bulma documentation (https://bulma.io/documentation/customize/with-node-sass/) it says to do an npm init and when prompted for an entry point, enter sass/mystyles.scss. I understand from previous post (What is "entry point" in npm init) that entry point during npm init should be your main.js file.
Why does Bulma documentation recommend making the custom scss file the entry point?
I'm keeping project entry point at main.js, but unsure of implications (if any).
TL;DR
It doesn't matter as long as your project isn't meant to be installed as a dependency.
The longer answer
To clearify what you read in the post about the NPM entry point:
The entry is used when users install your package from NPM and requires it. This means that if your entry is main.js,
const package = require("yourpackage");
will be the same as writing
const package = require("./node_modules/yourpackage/main");
Because you don't need this syntax inside your project, it doesn't affect anything, like compiling Sass, inside your project.
If the package is supposed to be published and installed as a dependency, however, you have to think about your entry point. If the project is primarily a Sass/SCSS package, I'd recommend setting the value to your main Sass/SCSS file, as there are Sass/SCSS processors that make use of the entry point.
That's also why the Bulma docs recommend setting the entry point to the Sass file. But in the end, it's your decision.
In my app, I have these dependencies:
TypeORM
typeorm-linq-repository AS A LOCAL INSTALL ("typeorm-linq-repository": "file:../../../IRCraziestTaxi/typeorm-linq-repository"), who has a dev dependency AND a peer dependency of TypeORM
The reason I use a "file:" installation of typeorm-linq-repository is that I am the developer and test changes in this app prior to pushing releases to npm.
I was previously using node ~6.10 (npm ~4), so when I used the "file:" installation, it just copied the published files over, which is what I want.
However, after upgrading to node 8.11.3 (npm 5.6.0), it now links the folder rather than copying the published files.
Note, if it matters, that my environment is Windows.
The problem is this: since both my app and the linked typeorm-linq-repository have TypeORM in their own node_modules folders, TypeORM is being treated as a separate "instance" of the module in each app.
Therefore, after creating a connection in the main app, when the code that accesses the connection in typeorm-linq-repository is reached, it throws an error of Connection "default" was not found..
I have searched tirelessly for a solution to this. I have tried --preserve-symlinks, but that does not work.
The only way for me to make this work right now is to manually create the folder in my app's node_modules and copy applicable files over, which is a huge pain.
How can I either tell npm to NOT symlink the "file:" installation or get it to use the same instance of the TypeORM module?
I made it work pretty easily, although I feel like it's kind of a band-aid. I will post the answer here to help anybody else who may be having this issue, but if anybody has a more proper solution, feel free to answer and I will accept.
The trick was to link my app's installation of TypeORM to the TypeORM folder in my other linked dependency's node_modules folder.
...,
"typeorm": "file:../../../IRCraziestTaxi/typeorm-linq-repository/node_modules/typeorm",
"typeorm-linq-repository": "file:../../../IRCraziestTaxi/typeorm-linq-repository",
...