Separate skeleton specific code from app code.

[darkadept]

Is there a way to keep the framework code separate from the app code? (For example resolveModuleSource.js in src\server). This would make adding something like eslint a bit easier. It would also make it easier to modify the example app. Maybe have a \lib for framework code and a \src for application specific code?

Also (this may be a new issue), would it be possible to make the example a bit more modular? For example, be able to rip out SSR if it's not needed. I'd be happy enough if there was just a README file showing how to remove certain features.

I'm still figuring out how all the pieces work together but I'll see if I can contribute anything. (BTW, awesome skeleton. Exactly what I'm looking for!!)

[jedwards1211]

I think util would be a good place for resolveModuleSource.js. Though I intend to lint the framework code as well as the app code. I'm pretty busy, so I'd prefer to focus on making the features I chose solid and leaving customization up to users to figure out. But if you mean using Meteor as the web server, you'll want to get rid of meteor-imports-webpack-plugin and use webpack externals for meteor packages instead to avoid duplicating the js that Meteor serves up.

[darkadept]

+1 for linting the framework too. util would be great. (I use the super strict air-bnb eslint config. That's probably not something you'd want to put in the framework though).

Yeah, I was more thinking about a readme to show how to remove certain features. I'm currently going over the code line by line to see how it's all put together and then hopefully I'll be able to lend some assistance. I think the feature-set you chose is a perfect start. No need to change that. I don't want to use Meteor as the web server. I'm very happy with the Express method. So fast!

Again, thanks for the work you're doing here. I'm currently using your old meteor-webpack-react code for my some apps and have hit a lot of the limitations with it. Time to move to crater!

[jedwards1211]

Cool, feel free to try my jscodeshift script to add meteor imports:

module.exports = function(file, api) {
  const j = api.jscodeshift

  const newImports = []

  const shifted = j(file.source)

  function checkImports(identifiers, module) {
    if (typeof identifiers === 'string') identifiers = [identifiers]
    const used = identifiers.filter(name => shifted.find(j.Identifier).filter(i => i.value.name === name).size())
    if (used.length) newImports.push(`import {${used.join(', ')}} from '${module}'`)
  }
  checkImports('Meteor', 'meteor/meteor')
  checkImports('Mongo', 'meteor/mongo')
  checkImports('Tracker', 'meteor/tracker')
  checkImports('EJSON', 'meteor/ejson')
  checkImports('ReactiveVar', 'meteor/reactive-var')
  checkImports('Session', 'meteor/session')
  checkImports(['Match', 'check'], 'meteor/check')
  checkImports('Accounts', 'meteor/accounts-base')

  const finalImports = newImports.filter(i => file.source.indexOf(i) < 0)

  if (!finalImports.length) return file.source
  return finalImports.join('\n') + '\n' + file.source
}

[jedwards1211]

I just wrote a babel plugin to transform meteor imports, I'll make the app skeleton use that instead of resolveModuleSource.js soon

[darkadept]

Ok. I went over most of the code now. You're changing things faster than I can read them! :-). I've put my notes in this gist: https://gist.github.com/darkadept/43b67782f81fcacf9edbf8319fcf35a9.

I propose the following:

• Move index.js and devServer.js out of /src/server. Maybe into /src/framework. Or even /util although that doesn't seem quite right.
• Could createSSR.js and Html.js be moved as well? It needs access to the routes and makeReducer, but otherwise is fairly app agnostic.
• Even parts of server.js could be split out into functions.

I guess what I'm getting at is moving that code out of /src (or at least keeping it separate) so that it's easier to keep the skeleton up to date with new changes while still working on an app that uses the skeleton. I think this is all less of a deal now since you've cleaned up a bunch of stuff.

The babel plugin to transform meteor imports is marvelous!

[jedwards1211]

createSSR.js, Html.js, and server.js do contain app code that people might want to change (e.g. adding express middleware, changing the page title, adding stuff to the <head>, etc), so I'm not in favor of moving them out. I'm not sure how best to server.js up into functions, but post some ideas here if you have them. Moving index.js out would make sense, in fact it controls what folder piping is watching, so really it should be in the src folder. (I thought I had moved it there awhile ago, maybe I stomped on my own change?) Moving devServer.js out would make sense too. Yeah I'm a lot happier with the babel plugin. In the grand scheme of things I almost want to make something that installs and transforms Meteor packages straight into node_modules, but that would be a hell of a lot more work than just running boot.js.

[jedwards1211]

One other cool thing is babel-plugin-webpack-loaders but it's still really experimental. It would be cool to eventually not have to webpack anything for the server side in production...

[jedwards1211]

It is kind of an awkward issue; on the Meteor extreme the framework is completely separate and runs your code, and you can constantly get updates without having to change your code (until having to add Meteor imports recently, that is). In this case (inspired basically by Meatier) it's a bunch of transparent boilerplate that you can tweak any way you want, but it's more difficult to merge in changes from the app skeleton. Seems kind of hard to find a happy medium...

[darkadept]

Yup. I totally agree. It is a tricky thing. I'd probably be happy enough with moving index.js and devServer.js out of src.

Based on the webpack config and package.json I guess the "special" folders/files right now are:

• /src/client/index.js - Referenced in webpack config as the client entry point
• /src/server/ - Ignored by webpack (IgnorePlugin)
• /src/server/devServer.js - Referenced by npm start in package.json
• /src/server/index.js - Referenced by npm start in package.json
• /src/server/server.js - Referenced by /src/server/index.js and is the "entry" point for the server.
• /src/styles/global/ - CSS not passed through PostCSS (from webpack config)

Everything else I can juggle around without worrying about checking webpack config or reading too deep into server/devServer.js and server/index.js. From the perspective of someone starting out with this framework I guess I'd need to know about those "special" folders and files.

Yeah, if devServer.js and index.js aren't in /server/ then there are fewer "special" items to be concerned about.

One question though, if I put some server code at a location like: /src/module1/server/myServerFile.js and import it from /src/server/server.js what does webpack do with it? If it's not referenced from /src/client/index.js it would just be ignored on the client, right? What's the purpose of the webpack IgnorePlugin ignoring /server/?

[jedwards1211]

Actually I need to get rid of that IgnorePlugin. I think that was from Meatier code I copied... Yeah, there should be no worries about importing server code from elsewhere.

[jedwards1211]

Okay, I'm confusingly choosing to rename server.js to index.js (after moving the original index.js up to src, because I like using index.js to indicate the entry point for a directory. PRs #20 and #21, tonight or tomorrow I'll check that the CI builds passed and merge them.

[jedwards1211]

I've moved devServer.js and index.js out of src/server now, so I'm closing this. I did another round of sweeping changes that massively simplified the start and prod scripts and added a debug script, as well as supporting windows -- check it out!