How/Why do Typescript/Electron/Webpack modules have absolute paths?

Question

I am using react-dates in an electron project, which requires initialization via:

 import 'react-dates/initialize';

This internally sets up some variables to be used later. The problem is when I next enter the code where these variables are used, I get an exception because they are still null.

It turns out the Chrome/Electron is treating these as 2 separate files, even though they are the same file on disk. When breaking in the setup file, Chrome reports the following paths (first access/second access)

C:\src\Project\node_modules\react-with-styles\lib\ThemedStyleSheet.js
webpack:///./node_modules/react-with-styles/lib/ThemedStyleSheet.js

Ok: thats odd - what gives? Where/how could this happen? I assume it's something to do with my webpack setup - I am using the TsConfigPathsPlugin & output/paths if that matters. From my webpack:

/**
 * Base webpack config used across other specific configs
 */

import path from 'path';
import webpack from 'webpack';
import { dependencies } from '../package.json';

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');

export default {
  externals: [...Object.keys(dependencies || {})],

  module: {
    rules: [
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              cacheDirectory: true
            }
          },
          'ts-loader'
        ]
      },
      {
        test: /\.js$/, // Transform all .js files required somewhere with Babel
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            cacheDirectory: true
          }
        }
      }
    ]
  },

  output: {
    path: path.join(__dirname, '..', 'app'),
    // https://github.com/webpack/webpack/issues/1114
    libraryTarget: 'commonjs2'
  },

  /**
   * Determine the array of extensions that should be used to resolve modules.
   */
  resolve: {
    extensions: ['.js', '.ts', '.tsx', '.json'],
    plugins: [new TsconfigPathsPlugin({ configFile: './tsconfig.json' })]
  },

  plugins: [
    new webpack.EnvironmentPlugin({
      NODE_ENV: 'production'
    }),

    new webpack.NamedModulesPlugin()
  ]
};

My tsconfig uses baseUrl to remap paths

{
  "compilerOptions": {
    "target": "es5",
    "baseUrl": "./app/",
    "jsx": "react",
    "module": "es2015",
    "moduleResolution": "node",
    "noUnusedLocals": true,
    "pretty": true,
    "sourceMap": true,
    "resolveJsonModule": true,
    "lib": ["dom", "es5", "es6", "es7", "es2017"],

    "allowSyntheticDefaultImports": true // no errors with commonjs modules interop
    //"strict": true,
    //"strictFunctionTypes": false,
  },
  "exclude": ["node_modules", "**/node_modules/*"]
}

Any suggestions on where/how else to figure this out much appreciated!

-- Edit:

I don't think there is two physical copies on disk, the output from npm -ls react-dates is as follows

C:\<project>\manager-ts>npm ls react-dates                                                                 
erb-typescript-example@0.17.1 C:\<project>\manager-ts                                                      
`-- react-dates@20.1.0                                                                                                                                                                                                                                                                                                                                                  
C:\<project>\manager-ts> 

Answer 1

This isn't a fix, and may not be awfully helpful for anyone else searching, but it did get me unblocked.

I created a second typescript module that defines the component using react-dates. This module is compiled to es5 and then "yarn link"-ed into my main app. Although I never figured out why there were differences (and I still/also get duplicate initialization warnings from ethers.js) this fixed at least this problem.