Currently, when publishing, the package only ends up containing a dist/package.json file...
However, running npm build normally at least puts the correct files in dist/source, although that's incorrect too, they should be in dist.
The problem with source files being in dist/source is the tsconfig inlude: it contains more than one folder (source and test) which results in subfolders for the dist folder.
ESLint 2 requires the test folder to be compiled in order to lint them. (see xojs/eslint-config-xo-typescript#15)
Having multiple tsconfigs might solve the problem (one extending the other) but is not nice in my opinion.
I experimented with this:
"scripts": {
"build": "del dist && tsc",
"prepack": "del dist && tsc --build tsconfig.release.json",
"test": "xo && nyc ava"
},
where the tsconfig.json extends the tslint.release.json config (which is the current normal config):
{
"extends": "./tsconfig.release.json",
"include": [
"test"
]
}
This way everything like linting works with all files and only the release builds the source folder.
I think I prefer having dist/source in the package, keeping the folder structure and having only a single tsconfig file running around.
The only problem I can think of are too long file paths in Windows…
No-one looks into node_modules so humans aren't a problem there I guess.
The problem with source files being in dist/source is the tsconfig inlude: it contains more than one folder (source and test) which results in subfolders for the dist folder.
That's just today: https://github.com/sindresorhus/got/commit/640c30bbe37fa399a6f9c96357d897f45e54f52f#diff-e5e546dd2eb0351f813d63d1b39dbc48R14 When this problem was discovered it only had source there.
Reopening as the build script is still broken. I had the same issue as before when publishing alpha.3 just now. I had to manually publish to fix it.
package.json is copied into dist, because we still have a package.json import call in the test. This screw up packaging.1, the fix in https://github.com/sindresorhus/got/pull/890/files#diff-21e9ddd93162651bd36f6e5bbfca8460R6, which used a manual path, fails because it doesn't account for the package.json being at the root, which is now two levels away instead of one, when packaged.// @jaulz
@szmarczak Maybe we should just drop importing package.json? Do we really need the Got version in the useragent string? I think it should be enough with just the name, which we can hardcode.
I agree.
Most helpful comment
@szmarczak Maybe we should just drop importing package.json? Do we really need the Got version in the useragent string? I think it should be enough with just the name, which we can hardcode.