I'm building a library with no default export, but a whole set of sub-exports. It's documentation for a set of APIs, so each API is exported from its own sub-directory. There is no central API info that should be exported from, say, dist/index.js, but instead, there's dist/api-one/index.js, dist/api-two/index.js, etc.
Currently, I'm importing like so: import { SomeFeatureOfApiOne } from 'my-package/dist/api-one
But it'd be nice to be able to get rid of the dist in the import path, since everything will have it. I know the files parameter just determines which directories are included in the export, so that doesn't work, and it appears that main is for the actual module file, not a directory.
Is there a way to do this? I was thinking of maybe a postinstall script that moves the sub-directories from /dist to root, but that feels super hacky to me, so I was hoping there was a neater way.
Add:
"exports": {
"./*": "./dist/*.js"
},
to your package.json
You can read more about "exports" here - https://nodejs.org/api/packages.html#subpath-exports
Related
I work on a component library and a React app that makes use of that component library. My component library looks like this when I build it:
/core
/components
/MyComponent
/utils
/hooks
This means when we import a component, it looks like this:
import '#our-package/core/components/MyComponent/MyComponent';
Is there a way we can make the components folder our entry point? The utils and hooks folders should not be accessible. Ideally, we could use:
import `#our-package/core/MyComponent/MyComponent`
I'm reading about the node main property you can use in package.json but it doesn't look like it works with folders. Is there another way to do this?
You could move your folder upwards, in the same directory as your package.json.
If you're targeting a newer version of Node.js, you can also make use of the new packages structure. You can basically say exactly where #our-package/core/subpath points at in your #our-package/core package. It has a whole system behind it that should allow you to export whole directories at certain subpaths.
I have the following file structure: ([] are folders)
[MySQL]
ConnectionPool.ts
Connection.ts
MySQL.ts
In my code, I am using typescript to develop the app, which will be built to javascript for the production version. The development version is tested directly from the uncompiled typescript files, using babel with the following configurations:
{
"presets": [
["#babel/preset-env", {
"targets": {
"node": "current"
}
}],
"#babel/preset-typescript"
],
"plugins": [
"#babel/plugin-transform-runtime",
[
"module-resolver",
{
"alias": {
... list of some aliases
}
}
]
]
}
My problem is the following, I do most of my imports like this:
import ConnectionPool from 'MySQL/ConnectionPool`
which works for me, as when I run my dev code, the compiler correctly identifies the file extension to .ts, and it also correctly identifies the built versions file extension to .js.
But if I want to import my MySQL.ts file, I can't do it this way, as I will get the following error: Error: Cannot find module './'. If I specify in my import statement the file extension, everything works correctly, but then, when I build my code, there will be no more .ts files in there, so I will get errors there.
Strangely, on the frontend, where I use webpack, I get no complaints about importing files without extension whose name is the same as a folders name in the same directory. What solutions do I have for this issue, which does not revolve around renaming my files or folders in the structure?
Rename your file MySQL.ts to index.ts and move it into the folder MySQL
In the meantime, I resolved my problem by explicitly specifying .ts as the file extension, and when building the code, using the babel-plugin-transform-rename-import to replace the .ts extensions to .js extension.
I won't accept this as the correct answer, as this is too hacky for me, so if a better solution comes up, I am still open for it.
I don't believe what you want to do is possible, node will automatically include either the file or the directory but if both of them are called the same thing node will have no idea which one to import and it will always prefer one over the other.
Using import Example from 'example' will have node search either for any files called example.js or directories called example with an index.js and it will only load one of them.
The reason webpack does it correctly is because webpack will never bundle a "directory", it will take what you've specified as an import and try all of the resolves extensions until it finds one and then it will import that file, so you'll never have conflicting files with directories with webpack.
I thought maybe a solution is to use aliasing in your typescript config so that you can use import Example from '#example' and differentiate between your directories and files that way. Then you can also do import Example from 'example' if you just want to load the file itself. But even then I don't think that will even work because once it gets compiled to javascript you'll just have the same issue as before with conflicting paths.
That being said, while I understand being a little bit obsessed with naming conventions and small things, I really don't think you should be storing "mysql" outside of the "mysql" directory, for two reasons. The first reason is that it's part of that directory, that's what that directory is for, it contains the "mysql" stuff, so why would you want to store it outside. Secondly using a "index.ts" communicates something to other developers, when I open up a new project or directory I'm immediately looking for something called "index.ts" or similar, otherwise I have no idea where to even begin. Using "index.ts" is a good way to communicate to anyone that "this file right here is the one you're looking for, everything starts here". That being said, just call it index.ts and store it where it belongs.
You can try in your tsconfig.json to set moduleResolution to the classic strategy:
{
"compilerOptions": {
"moduleResolution": "classic"
}
}
Unfortunately, looking at the code, this seems to be impossible in your setup:
import is handled by module-resolver
module-resolver calls the NPM package resolve
resolve.sync checks for the no-extension case before testing extensions.
Given that most systems are going to follow Node module resolution, I think you're out of luck, without some manual aliases or moving files around.
FWIW, NodeJS says that extensions in import are mandatory.
I've started an application in typescript. I've learned about some features of TS and it looked like something, that could help me, hovewer, I don't work like I would expect. The documentation of TS says something about Path mapping in Module resolution chapter. This module mapping can, if I understand it correctly, save me few or even lot of double-dots in import. So I have created a "inc" directory with one file (at this time), that will be included in multiple files in multiple directories. Into tsconfig I've written following:
"baseUrl": ".",
"paths": {
"#inc/*": [ "inc/*" ]
}
Now, I would expect, that using import { X } from "#inc/somefile" (even from file resting somewhere deep in folder tree) would result in importing that export X from ./inc/somefile.ts (or .js, when runnning).
Hovewer, the compiler/transpiler will leave the import statement intact, so when I try to run this code using node.js, it will die because there is no #inc/somefile - node doesn't read tsconfig and tsc doesn't create any mapping functions.
I can, of course, read and parse the path element by hand in some kind of require wrapper, but I believe there is something I'm doing wrong and/or better way to achieve this.
Thank you for your replies.
Remember that
if you then try to exeute the compiled files with node (or ts-node), it will only look in the node_modules folders all the way up to the root of the filesystem and thus will not find the modules specified by paths in tsconfig. -- introduced in tsconfig-paths readme.
In conclusion, directly require tsconfig-paths into dependencies list and load tsconfig file on run could be a quick solution.
I used to put all my tests together inside of __test__ directory. But I decided to put each test files into each component's directory with different name convention.
Old Structure:
src/
__test__/
example.test.js
example2.test.js
New Structure:
src/
components/
example/
example-controller.js
example-model.js
example-route.js
example-test.js
As naming and location of a directory changed, I updated all import statement and namings for according files. I was using default feature of Jest but since I changed test file name to example-test from example.test I also updated package.json
"jest": {
"testRegex": "./src/components/*/.*.-test.js$"
},
Problem is when I run the project, npm run it throws
beforeAll((0, _asyncToGenerator3.default)( /#PURE/_regenerator2.default.mark(function _callee() {
ReferenceError: beforeAll is not defined
any idea why it is happening?
Try regextester with your file-paths before getting frustrated. Also, look at some popular existing javascript projects using jest and check their jest configurations to see how the community is settling on project structure. It may seem simple to follow others, but most software engineers don't work alone, and usually agree on good practices.
Consider coming back to this project in a year; You are changing the default behavior of a simple process that works beautifully out of the box. Someone may hate you later after a git blame.
If all you want to do is check all -test.js files, slowly modify the default config until you match the file paths you want.
(/__tests__/.*|(\\.|/)(test|spec))\\.[jt]sx?$
Should probably (for you) be:
(.*/src/.*(-test).jsx?)
I have a project and installed for example underscore and marked via npm install. When I launch node in my project root folder, I can require both with var __ = require("underscore"), similar for marked. This is how I use both libraries in my backend, if needed. Now I want to write a myscript.js which is delivered to the browser, it's referenced for example in my index.html file. In this script, I want to use both mentioned libraries as well.
For this to work, I think there are two methods:
inline the required files (I think I prefer this)
copy the required js files into a separate directory, and use require.js in the browser.
In neither case I want to point a program to where the libs are found, similar to node, which knows what to do by just saying require("lib").
My questions are:
Did I understand this correctly?
Is grunt-contrib-requirejs exactly the the thing I need to automate this process?
Can someone provide me with a snippet of code or point me to a blog post or something? I think I lost the overview, I found the documentation but many things are confusing.
Here is what I have so far:
Configuration for my Grunt task:
requirejs: {
compile: {
options: {
baseUrl: "./",
name: "src/main.js",
out: "build/result.js"
}
}
}
My main.js:
var _ = require("underscore")
function foo(values)
{
_.find(values, function(value){ return false; });
}
The result:
function foo(e){_.find(e,function(e){return!1})}var _=require("underscore");define("src/main.js",function(){});
... not exactly what I thought.
While this does not answer my original question, I found out that using node modules is not exactly the way to go for frontend stuff, I found bower. Anyway, this whole thing is very frustrating.
Bower allows me to install required packages, and then there are modules for grunt which allow the JS files either to be "plugged" into the HTML document within a special section, or to be concatenated into one file. Bower-ready modules should ship with a bower.json file. This reliefes me fron the work of manually collecting all needed js files from the node_modules folder like I was afraid of in the question.