labaneilers / hashly Goto Github PK

perhaps a simple format string could allow us to specify this. Currently its:
{filename}-hc{hash}{ext}

Hi, i want to run hashly inside a build-all.js file and it's dosn't work.

This is my code.

var shell = require('shelljs');
config.push(input + ' ' + output);
config.push("--base-dir " + process.env.PWD);
config.push("--manifest-format \"json\"");
config.push("--rename-format \"{basename}-{hash}{extname}\"");
config.push("--verbose");
config.push("--amend");

shell.exec("hashly " + config.join(" "));

and this is my line

hashly css/ dist/ --base-dir $PWD --manifest-format \"json\" --rename-format \"{basename}-{hash}{extname}\" --verbose --amend

with npm run works fine, buts inside the script with shelljs nop.

any help?

Consider checking the length of the hashed file matches the source.

Check performance and memory usage. If performance is a problem due to reading binary files, change from a content/md5 strategy to a hash of the file byte size, perhaps seasoned with a few bytes from the middle of the file.

Hey there! Nice plugin, thanks for that!

How can I use it with multiple sources? Could you provide an example please?

Best regards

Virtual paths in the resulting manifest should use forward slashes, physical paths should use backslashes

Seems like the modified contents of the processed css files (which is actually done in createManifestEntryCss and stored into the entry.transformedText value) is never stored to the disk.

I've updated the code in the processEntry function where the actual copy/write is done and added a check for entry.transformedText:

// Copy the original file to the hashed path
if (transformedText) {
    fsutil.writeFileSync(entry.hashedPathPhysical, transformedText, "utf8");
    transformedText = null;
} else if (entry.transformedText) {
    fsutil.writeFileSync(entry.hashedPathPhysical, entry.transformedText, "utf8");
} else {
    fsutil.copySync(entry.pathPhysical, entry.hashedPathPhysical);
}

With this change css files are processed correctly.
I'll create a pull-request for this in a moment ;)

I'm playing with the source map rewriting (which is a great feature!), but finding the behavior is a bit different than I expected for the rewritten path.

Since the .map file is in the same directory as the source (and this is assumed in the code), the sourceMappingURL traditionally just includes the name of the map file without any pathing.

However, when the source map URL is rewritten, it ends up being done with the full path, starting from targetPath. This ends up breaking the sourcemap for me, since targetPath is NOT my wwwroot. Using the sourceMapURLPrefix option is one workaround, but it also requires me to know the wwwroot where the file will be hosted.

I think it might be better to default to leaving the source map without any path component at alll, just like in the source input. @hsingh23 any thoughts on this, since you originally wrote the code?

I'm happy to submit a PR but this is a "breaking" change.

This would be faster, because we would skip recursion through hidden directories (i.e. .git, .svn), and would make debugging easier. We can also probably separate the file selection concern more cleanly from the file processing concern.

/assets/favicons/favicon1.bmp is incorrect on both unix and windows. Check out the height:
{
"path": "/favicons/favicon1.bmp",
"hashedPath": "/favicons/favicon1-hced2f9fa827b490a4621729afb8533060.bmp",
"width": 360,
"height": 4294967010
},

It should be 270. Looks like a bug in image-size.

Start with a flat file format, perhaps create XML

Thanks for creating hashly, it works very well, but after some time now working with one of the latests releases of node.js it just hangs upon execution.

This wont work with the following versions of node and npm, it just hangs upon execution:
node(v11.2.0) npm(6.4.1) on macOS 10.13.6

npm run bug

hashly --help

With no output.

Package details:

{
  "name": "test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "bug": "hashly --help"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "hashly": "^0.6.0"
  }
}

Passing --no-css-processing doesn't actually set the option to true, but -n does work. --no-css-processing=true works, however.

Note: This may just be in windows (powershell). Need to test it.

This would be useful for housekeeping when a directory is processed repeatedly over a long period of time. The argument should specify the number of days old a file should be before it can be deleted.

Allow, when passing a list of files to process, updating an existing manifest (instead of deleting it and starting from scratch). We could load the manifest into memory, update it, and rewrite it. We could also optimize so as not write files that already exist with correct hashcode, or look at timestamps to avoid even recalculating hashcodes at all (also see issue #18).

We'll need to add functionality to parse a manifest to the manifest format adapters. I'm not sure how this will work with non-self describing adapters, which may have data written from plugins; perhaps we'll just include a list of extra fields, which can be accessed by index. The same plugins would have to be loaded both times.

Hey, thanks for the useful tool!
My question is that is there any chance to omit transformedCssText in the manifest file? Seems like it can reduce the manifest file significantly.

This would allow us to opt-out of generating hashed versions of source files (i.e. coffeescript, less, unminified source js and css)

NPM can apparently install the main exe along with a corresponding .cmd file for windows in the global node_modules folder.

Allow specifying the path for the manifest.

• In --clean, mode, the manifest should be deleted from this location.
• Validate file extension matches --manifest-format option (?)

This would allow inlining small images in HTML from server code, even when the static files aren't deployed to the same server as the web application.

Allow path list to be piped in through stdin, and process only those files. If there is an existing manifest, it should be amended by default (see issue #16)

Generating hashcodes for images doesn't necessarily mean we have to md5 the whole file. We could, for example:

• Use the file length. 99.9% of the time, this is good enough
• Use the middle x bytes or last x bytes, or every 10th or 100th byte, etc.

Initial implementation is a proof of concept. Here's some bugs:

• Support multiple url() per line. Currently, the code parses line by line, and assumes there's only 1 url per line. This wont be true for minified CSS.
• Support unix/windows line endings. Currently, the parser just splits the file on \n.
• Preserve line endings. Currently, the parser just writes unix line endings.