Remove "path" dependency from library

[pfeigl]

Please remove the path dependency from the library. It's a node function and thus not available in browsers by default.

Current builds of Angular 6 won't work because path cannot be resolved.
Also examples on Stackblitz fail, see i.e.: https://stackblitz.com/edit/angular-6-mime-types

I tried installing the path package from npm (which is super outdated) but this also fails because path internally depends on process which is also not available.

Here's the actual implementation: https://github.com/nodejs/node/blob/master/lib/path.js#L836
We could either migrate this into the project or take a much simpler approach using a very basic regex or split algo.
Here's some very good information on it: https://stackoverflow.com/questions/190852/how-can-i-get-file-extensions-with-javascript/1203361#1203361

I'd also happily provide a PR if help is wanted.

Thanks!

[dougwilson]

Hi, thanks for taking a look! Sorry it doesn't work for your situation: this module is only advertised to work for Node.js, so I'm surprised it's being used in another environment. We can support additional environments, though. Here are my thoughts:

1. First, we need to add this environment to the test suite, so we are actually testing and supporting it, so we can ensure that the changes made resolve the issue and that we don't introduce any breaking changes to your environment in the future.
2. Ideally we don't break compatibility here, so it should work the same, that would probably mean we'd need the while of what we're using from path. Unless we also copy in the entire test suite for those routines (we don't have any tests that cover all the edge cases that path takes care of, as we trust that path itself has already been tested), we probably want to just bundle that into a module on npm and then we can just change our dependency from path to that new module and that would resolve the issue.

Thoughts?

[pfeigl]

Wasn't aware how strictly the "Node.js" was meant ;-) Anyways I like opening up the library for other environments.

That said, I don't like taking over the code of path. Neither copying into this project nor hosting it as a seperate project. Specifically hosting it elsewhere often leads to unmaintained code (see https://github.com/jinder/path).

What I would prefer is adding a function like the following (including required tests):

function getExtension(path) {
    var basename = path.split(/[\\/]/).pop(),  // extract file name from full path ...
                                               // (supports `\\` and `/` separators)
        pos = basename.lastIndexOf(".");       // get last position of `.`

    if (basename === "" || pos < 1)            // if file name is empty or ...
        return "";                             //  `.` not found (-1) or comes first (0)

    return basename.slice(pos + 1);            // extract extension ignoring `.`
}

(See https://stackoverflow.com/a/12900504, seems to cover pretty much every case. I tested quite some use-cases and they all seemed to give the expected result).

The beauty of this is, that we are totally within a controlled js only environment without any external dependencies (except mime-db ofc).

For the environment-related test-suite: It is probably good enough to run the existing tests with karma in a real browser environment. I guess we don't even have to write new tests, just make sure the existing ones run within the expected environment.

[dougwilson]

Yea, as long as that function is functionally identical to the Node.js path.extname. I just don't want to introduce a breaking change here ideally. Just publish that as a separate module and we can depend on that instead of path. As for the karma tests that sounds good to me.

[dougwilson]

I was taking a look at npm and there are a whole bunch of file extension modules. Probably at least one of those we could use here.

[pfeigl]

Sounds good, how should we proceed on this? Should I prepare something and send as a PR?

[marlon360]

I made a PR #52 which solves this.
I need this for my Angular v6 Application.

[dougwilson]

@pfeigl @marlon360 someone pointed me to that mime module has a 2.x series now (it was 1.x when this was forked from mime) and that seems to have not only web browser support, but it's significantly smaller when used in the browser than this module.

See https://github.com/broofa/node-mime#browser and https://github.com/broofa/node-mime#mime-vs-mime-types-vs-mime-db-modules

Does the mime module work for your use-cases? It looks like the 2.x series added a bunch of new functionality that maybe this module should copy one day, not sure. Of course, it seems like that module also has first-class browser support while, at least from what it sounds like from you two, this module does not. Not sure how that one is achieving browser support, but now I'm curious.

Thought I'd pass along my findings here.

[marlon360]

The mime module should work in Angular, because it does not rely on any built-in NodeJS modules. This module does not use the path module. This is how they get the file extension:

var last = path.replace(/^.*[/\\]/, '').toLowerCase();
var ext = last.replace(/^.*\./, '').toLowerCase();

var hasPath = last.length < path.length;
var hasDot = ext.length < last.length - 1;

return (hasDot || !hasPath) && this._types[ext] || null;

But this module does not work with Angular CLI projects, because internally they require json files without a file extensions:

module.exports = new Mime(require('./types/standard'), require('./types/other'));

which leads to this error:

ERROR in ./node_modules/mime/index.js
Module not found: Error: Can't resolve './types/other' in '/www/mime-type-ng/node_modules/mime'
ERROR in ./node_modules/mime/index.js
Module not found: Error: Can't resolve './types/standard' in '/www/mime-type-ng/node_modules/mime'

Angular cannot resolve .json extensions, so it does not find the module. Unluckily the maintainer do not want to add the extensions:

Note the bit at the bottom about the CommonJS spec explicitly saying module names should not include extensions.

The mime module uses a bundler to create a browser version. The bundler is not integrated in the project, they use a website which automatically browserify the module.

This would be your package: https://wzrd.in/standalone/mime-types@latest
But in Angular projects you cannot import modules from a webaddress, but it works for browser projects.

[pfeigl]

Back again, have been out on a long weekend. Actually I'm already using mime in an angular-cli project. This is how:

import Mime from "mime/Mime";

export const mimeTypes = new Mime(require("mime/types/standard.json"));
mimeTypes.define(require("mime/types/other.json"));

In the end I just mimic what mime has in it's `index.js´ (see https://github.com/broofa/node-mime/blob/master/index.js) just that I add the required extensions. Now I can just do the following:

import { mimeTypes } from "../../shared/mime-types";
...
mimeTypes.getExtension(this.result.contentType)

I also looked into setting https://webpack.js.org/configuration/resolve/#resolve-extensions within angular-cli, but this is not configurable from externally and also eject is not yet available (and also not something I would want to do).

Overall it works well, but forces me to have my own wrapper around mime which I didn't like, but hey ...

[LRNZ09]

It also crashes on React Native because of this.

[dougwilson]

So the summary here is that the path dependency is a part of Node.js core. It is used for a good reason and we're not interested in removing it. Your alternative is to just use the mime module. This module was made to fix issues in mime 1.x, as noted in the README. The mime module has since revived and released a 2.x which is great. It uses the same data source as this module, so has all the same mappings.