Exploring dependencies fails when targetExtension is set

[rudi-c]

Description

When a plugin uses targetExtension to compile a non-Javascript file to a Javascript file, deppack won't read and follow the require statements in that compiled file to include the dependencies in the final output app.js.

Environment

1. Brunch: 2.10.9
2. Phoenix
3. NPM: (npm v2 is not supported)

package.json contents

{
  "repository": {},
  "license": "MIT",
  "scripts": {
    "deploy": "brunch build --production",
    "watch": "brunch watch --stdin"
  },
  "dependencies": {
    "babel-preset-react": "^6.24.1",
    "phoenix": "file:deps/phoenix",
    "phoenix_html": "file:deps/phoenix_html",
    "react": "^15.6.1",
    "react-codemirror": "^1.0.0",
    "react-dom": "^15.6.1"
  },
  "devDependencies": {
    "@types/react": "^15.0.37",
    "@types/react-codemirror": "^0.2.7",
    "@types/react-dom": "^15.5.1",
    "typescript": "^2.5.0-dev.20170707",
    "typescript-brunch": "github:rudi-c/typescript-brunch",
    "babel-brunch": "~6.0.0",
    "brunch": "2.10.9",
    "clean-css-brunch": "~2.0.0",
    "css-brunch": "~2.0.0",
    "javascript-brunch": "~2.0.0",
    "uglify-js-brunch": "~2.0.1"
  }
}

brunch config contents

exports.config = {
  // See http://brunch.io/#documentation for docs.
  files: {
    javascripts: {
      joinTo: "js/app.js"

    },
    stylesheets: {
      joinTo: "css/app.css",
      order: {
        after: ["web/static/css/app.css"] // concat app.css last
      }
    },
    templates: {
      joinTo: "js/app.js"
    }
  },

  conventions: {
    // This option sets where we should place non-css and non-js assets in.
    // By default, we set this to "/web/static/assets". Files in this directory
    // will be copied to `paths.public`, which is "priv/static" by default.
    assets: /^(web\/static\/assets)/
  },

  // Phoenix paths configuration
  paths: {
    // Dependencies and current project directories to watch
    watched: [
      "web/static",
      "test/static"
    ],

    // Where to compile files to
    public: "priv/static"
  },

  // Configure your plugins
  plugins: {
    babel: {
      presets: ["es2015", "react"],
      // Do not use ES6 compiler in vendor code
      ignore: [/web\/static\/vendor/]
    },
    brunchTypescript: {
      target: "ES2015",
      module: "ES2015",
      jsx: "preserve",
    }
  },

  modules: {
    autoRequire: {
      "js/app.js": ["web/static/js/app"]
    }
  },

  npm: {
    enabled: true
  }
};

Diagnostic

My use case is compiling Typescript files (with React in this case). I start with editor.tsx, which then gets converted to editor.jsx then later editor.js using targetExtension. However, the fileList key-value map still has editor.tsx. This means that inside deppack, in explore.js:exploreDeps, when it does the isJs check, it can't find editor.js in fileList.

I'm not sure how I'd go about fixing this given that Brunch operates on a per-file basis which would make mutating fileList after compilation stages a risk endeavor. Furthermore, exploreDeps seems to do a lot of things at once, including handling events, and seems to require lots of context to modify.

[Thorn1089]

It's been over a year since this issue was filed. While it doesn't affect the last released version of typscript-brunch, to use a specific example, there is a commit in master which will cause the same breakage on the next release. This is a show-stopper in my mind -- there are vanishingly few production web applications where not including the dependencies from node_modules is an option, especially where this is a selling point of Brunch.

Overall I would agree with the sentiments of #1642 - Brunch is great when it works, but I can never trust an update to any piece of the ecosystem. The time saved is always eaten up by diagnosing the exact combination of patch versions for the core tool and the various plugins (Typescript, Sass, etc) I need.

It's even worse when issues like this sit fallow for a year. I see from open PRs that there is a Brunch 3.0 in the works. Is there a roadmap outlining the release timeline for this? Should we hold off on trying to fix issues like this ticket describes because they will be resolved in a major version? If so, how long should we we wait for that to happen?