Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concepts - Output #10

Closed
bebraw opened this issue Jun 29, 2016 · 18 comments
Closed

Concepts - Output #10

bebraw opened this issue Jun 29, 2016 · 18 comments

Comments

@bebraw
Copy link
Contributor

bebraw commented Jun 29, 2016

Stub.

Feel free to comment here if you have ideas on what this guide should cover. Link to potential resources too.

@bebraw bebraw changed the title Feature Guide - Output Concepts - Output Jul 24, 2016
@bebraw bebraw modified the milestone: Webpack 2 - Documentation MVP Aug 5, 2016
@michael-ciniawsky
Copy link
Member

@bebraw @TheLarkInn Working on it, loaders aswell, when the basic document structure stands a open PR for review

@michael-ciniawsky
Copy link
Member

michael-ciniawsky commented Sep 19, 2016

Output

[Intro]

Usage

[Description (basic)]
webpack.config.js
[Example (basic)]

[Description (advanced)]
webpack.config.js
[Example (advanced)]

Options

  • path
  • publicPath
  • library (maybe separated ?)
  • libraryTarget (maybe separated ?)
  • filename
  • chunkFilename
  • sourceMapFilename
  • jsonpFunction (maybe advanced ?)

Advanced Options

devtool

  • devtoolLineToLine
  • devtoolModuleFilenameTemplate
  • devtoolFallbackModuleFilenameTemplate

hotUpdate

  • hotUpdateFunction
  • hotUpdateChunkFilename
  • hotUpdateMainFilename

No section assign yet ( ? Ideas welcome :))

  • pathinfo
  • sourcePrefix
  • umdNamedDefine
  • crossOriginLoading

Are any of this options deprecated or should be avoided ? Roughly structure ok so far? :)

@skipjack
Copy link
Collaborator

@michael-ciniawsky structure looks good to me 👍 , just a heads up though: you might want to take a look #157, as all these options you're listing already have at least a start there. See the comments, we're currently trying to figure out how to divvy each section out. We're you planning on documenting each on this page or just linking to it?

@bebraw aside from the overlap here we should probably look at #156 as some of that is already done or started #157 as well.

@skipjack
Copy link
Collaborator

skipjack commented Sep 19, 2016

The structure @michael-ciniawsky laid out above looks like it could work very well for the split up we've been talking about in #157.

@bebraw
Copy link
Contributor Author

bebraw commented Sep 19, 2016

Yeah, there's some definite overlap. The point is that you can go into great detail in this document if we agree that the configuration page is an overview (quick reference).

@skipjack
Copy link
Collaborator

skipjack commented Sep 19, 2016

@bebraw but then we should just port all those detailed options from #157 to the individual Concepts pages like this one. I'm just going to go ahead and do that and merge #157 before any more overlap is created. If we want to rename the top-level nav items down the road we can. That work?

@michael-ciniawsky I'll use your structure to port things over and then you can create another PR to make any changes.

@bebraw
Copy link
Contributor Author

bebraw commented Sep 20, 2016

Yeah, merge is ok I think.

@michael-ciniawsky
Copy link
Member

We're you planning on documenting each on this page or just linking to it?

@gregvenech

Depending on how you guys plan to do it :), it's the intended structure + document each on the page, but yes I noticed early that it would get 'a smell' of the current docs quickly. The organisation/layout must be different somehow.

Is it possible to display the advanced options + example programmatically on the concept pages e.g via user selection

<select>
  <option value="beginner">Beginner</option>
  <option value="advanced">Advanced</option>
</select>

which hides all advanced options + example on ever page when beginner(default) is selected ? This goes in the direction like you and sokra discussed hiding advanced content in <details></details>, but maybe a diff between beginner and advanced in terms of two different 'walkthroughs' would make docs usage easier to follow at the beginning, manual clicking on each respective page's details could be enabled nevertheless for folks wanting to revisit a specified section. As @bebraw stated out the right amout of detail is the tricky and important part, speaking of output for example , chunking and sourcemaps + OccurenceOrderPlugin and friends are 'advanced' beginner contents imo.

When I started, the 'basic' example + options are straightforward to document, there are not much ambiguities, but the advanced options will cause confusion for beginners since it's unlikley they have dig into webpack internals (compiler, code gen) at this point of their journey.

@skipjack
Copy link
Collaborator

skipjack commented Sep 20, 2016

@michael-ciniawsky

Yea I do like the structure you described but it could get a bit lengthy having the full documentation for all of those options there. I really like that you tied in the other options that relate to output but aren't nested as options under output. I definitely think these ties should at least be linked to from the various configuration, concept, and api pages.

Is it possible to display the advanced options + example programmatically on the concept pages e.g via user selection...

Anything's possible 😁 ! Personally I think we can get a lot of that breakdown just by splitting up pages, organizing them (#93), and linking them -- creating an intuitive flow. Something like what you described could be useful but it would require some tweaks to the markdown parser or Page component to support it.

I'm working on splitting up #157 into multiple pages under a new Configuration section. I'm hoping to have it done and merged tonight. Maybe it's worth us quickly regrouping a little bit after and deciding on a distinct purpose for the pages within each section, i.e. Configuration, Concepts, API, etc., before diving in too much more. That way we can have a more consistent "game plan" when approaching new pages. @bebraw what do you think?

@bebraw
Copy link
Contributor Author

bebraw commented Sep 20, 2016

@gregvenech Yeah, we can sync after #157 is in a good shape and split up. I wouldn't get too stuck on the structure. It's easier to make judgment calls once there's something visible. I don't mind editing things into shape. 👍

@skipjack
Copy link
Collaborator

@bebraw perfect.

@michael-ciniawsky
Copy link
Member

@gregvenech @bebraw 👍 i wait until the split up is done, preparing contents meanwhile.

@skipjack
Copy link
Collaborator

skipjack commented Sep 21, 2016

@michael-ciniawsky it's been split and merged. @sokra already started revising the new Configuration section in #180. So I guess anything on how to use specific output options would go in /configuration/output while the why and what is output would go in /concepts/output... would you agree @bebraw, @TheLarkInn? (though obviously there will be at least a small amount of overlap)

@bebraw
Copy link
Contributor Author

bebraw commented Sep 21, 2016

Sounds good to me.

@michael-ciniawsky
Copy link
Member

@gregvenech 👍

Off topic but are there any notes besides the release note about the changes in modules (loaders -> rules) etc.? So I can update it and commit (concepts/modules, concepts/loaders)

@bebraw
Copy link
Contributor Author

bebraw commented Sep 22, 2016

@michael-ciniawsky Two sources for now: migration guide, gist.

@TheLarkInn
Copy link
Member

Any update on this? Can help if anyone is stuck.

@bebraw
Copy link
Contributor Author

bebraw commented Oct 17, 2016

Online already. Just forgot to close this one.

@bebraw bebraw closed this as completed Oct 17, 2016
dear-lizhihua added a commit to docschina/webpack.js.org that referenced this issue Jan 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants