Skip to content

resolve does not preserve require.extensions list and assumes only ['.js'] #137

Closed
tape-testing/tape
#396

Description

@snuggs

Greetings!

Having a situation where we are using tape which does not pass extensions to resolve. Have opened an issue here tape-testing/tape#395

That being said our situation is we use the .es ECMAScript extension with the following:

require.extensions ['.es'] = require.extensions ['.js']

Although we can achieve our needs with the previous tape issue/pr I feel it behoves resolve to use the default require.extensions list provided by node instead of only assuming ['.js'] here

var extensions = opts.extensions || ['.js'];
.

An easy enhancement would be to convert:

var extensions = opts.extensions || ['.js'];

to

var extensions = opts.extensions
  || Object.keys (require.extensions)

Please advise and will have a PR & tests up ASAP as we need this or have to call off using tape and resolve. Can also enhance documentation which should close #134 which @ljharb, and @call-a3 are working on as well.

Thanks in advance! /cc @brandondees

Activity

  1. ljharb commented on Sep 22, 2017

    @ljharb
    Member

    This would be a breaking change; require.extensions starts with .js, .json, and .node.

    You can certainly use resolve with require.extensions via the extensions option, however.

  2. TehShrike commented on Sep 28, 2017

    @TehShrike

    If this package's goal is to implement the node.js require.resolve() algorithm, isn't this something that should be fixed?

    Using a truncated default extensions list makes this library default to non-node-like behavior.

    Packages like got that require('./package') will break when bundled by bundlers that use node-resolve (which is all bundlers that I'm aware of).

  3. bmeck commented on Sep 28, 2017

    @bmeck

    It should be noted that both NODE_PATH and require.extensions have been deprecated for years. They also do not affect the ESM resolution algorithm. I would recommend moving off of relying on their usage.

  4. TehShrike commented on Sep 28, 2017

    @TehShrike

    That makes sense to me. Changing the hardcoded default to match the extensions given in the docs seems preferable.

  5. snuggs commented on Sep 29, 2017

    @snuggs
    Author

    @TehShrike hence https://github.com/browserify/resolve/pull/138/files

    This way even if someone is on some ancient deprecated api that's technically superfluous to the intent of what the library is assumed to accomplish. Feels quite awkward one would have to pass in the standard require.extensions to override the default require resolve "extensions". P.O.L.A. is real.

  6. added a commit that references this issue on Jan 4, 2018
    59c4cd8
  7. TehShrike commented on Mar 7, 2018

    @TehShrike

    Interested parties should go review #145.

  8. added a commit that references this issue on Apr 5, 2018
    a578a0f
  9. ljharb commented on Jun 16, 2018

    @ljharb
    Member

    Closing this in favor of #166, to centralize further discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions