Main entry point support

[sgentle]

I notice in your example webpack config you have { entry: './src/entry' }, which is a JS file that requires any PureScript modules that you need.

In my case, I just want to call Main.main, so mine looks like this: require('./Main.purs').main(); It seems like it would be cleaner if you could just use { entry: './src/Main.purs' } directly.

I believe the browserify/psc-bundle toolchain does something like this already. Would you consider adding it to purs-loader? I'm fairly new to PureScript, but happy to do the lifting with a bit of direction. (Though maybe #31 would make this irrelevant anyway.)

[ethul]

Thanks for checking out the purs-loader. I agree it would be handy to use Main.purs as the entry directly. I will have to look into whether webpack supports something like this.

[ethul]

This does in fact work. See: ethul/purescript-webpack-example@923f3c1d79cee40e6d6b488cd2f985f484e17af3

[Pauan]

@ethul I just tried building https://github.com/ethul/purescript-webpack-example but it didn't work:

/*!************************!*\
  !*** ./src/Entry.purs ***!
  \************************/
/***/ function(module, exports, __webpack_require__) {

// Generated by psc version 0.10.1
"use strict";
var $foreign = __webpack_require__(/*! ./src/Entry.js */ 1);
var Prelude = __webpack_require__(/*! ./bower_components/purescript-prelude/src/Prelude.purs */ 2);
var Control_Monad_Eff = __webpack_require__(/*! ./bower_components/purescript-eff/src/Control/Monad/Eff.purs */ 43);
var Control_Monad_Eff_Unsafe = __webpack_require__(/*! ./bower_components/purescript-eff/src/Control/Monad/Eff/Unsafe.purs */ 45);
var Example_Test = __webpack_require__(/*! ./src/Example/Test.purs */ 47);
var Example_Foo = __webpack_require__(/*! ./src/Example/Foo.purs */ 49);
var Example_Foo_Baz = __webpack_require__(/*! ./src/Example/Foo/Baz.purs */ 53);
var result = Control_Monad_Eff_Unsafe.unsafePerformEff($foreign.hot);
module.exports = {
    result: result, 
    hot: $foreign.hot
};
//# sourceMappingURL=index.js.map

Notice that it does not call anything, therefore it does nothing when running node bundle.js

The point of this issue is to automatically call the main Eff from the Main module, just like when using psc-bundle --main Main

[ethul]

Agreed. You're totally correct. I was too soon on closing this. I've been updating the example further. Please see: https://github.com/ethul/purescript-webpack-example/blob/30265626f89b605bf24be94a8f7fadd2610bcd23/src/Example.purs#L17-L25

[Pauan]

@ethul With psc-bundle, it is not necessary to use unsafePerformEff, instead you simply return an Eff from main, which is idiomatic in PureScript.

I think purs-loader should support a main option, similar to psc-bundle

[Pauan]

@ethul Hm, actually, I thought about it some more. Webpack supports multiple entry points, so you would really want to be able to specify a different main per entry point. That complicates things a lot.

If you only have a single entry point, you can currently use the following to specify the main:

module: {
  loaders: [
    {
      test: /\.purs$/,
      loader: "purs-loader",
      exclude: /node_modules/,
      query: {
        bundle: true,
        pscBundleArgs: {
          main: "Main"
        },
        src: ["bower_components/purescript-*/src/**/*.purs", "src/**/*.purs"]
      }
    }
  ]
}

[ethul]

Right. So you can return an Eff instead of performing the IO, but I am unsure how webpack would know to run this.

Maybe the loader could create a wrapper entry module that invokes this function. Supporting a main for each entry could maybe be done in a similar way if the loader was able to know which modules are "entry modules" then it can wrap each of the entries, and we'd need a configuration that we can lookup the right main function using the module name (as one idea).

E.g.,

{
  moduleMainFunctions: {
    'ExampleEntry1': 'example1',
    'ExampleEntry2': 'example2'
  }
}

[ethul]

@saevarb Thanks for your feedback.

Does your issue relate to #33 or are you describing a new issue?

If you are able to provide a little more explanation on how your issue fits into with #33, I'll be better able to investigate this.