Skip to content
This repository has been archived by the owner on Sep 7, 2020. It is now read-only.

Handling markdown assets #147

Closed
bartgryszko opened this issue Feb 15, 2016 · 18 comments
Closed

Handling markdown assets #147

bartgryszko opened this issue Feb 15, 2016 · 18 comments

Comments

@bartgryszko
Copy link

I'm wondering how statinamic could handle assets from markdown by webpack. I was able to create webpack loader by using html-loader + markdown-it but the problem in this solution is current .json files generation in https://github.com/MoOx/statinamic/blob/e7149484695d9b1790775f3e33dc99fb5db9758b/src/md-collection-loader/index.js#L78. I've tried using Loader.exec but run into this webpack/webpack#667

Any ideas how this could be handled?

@thangngoc89
Copy link
Contributor

I'm pretty sure @MoOx would love to have this implemented in the core #94 (comment)

I'm not familiar with writing a webpack loader. Could you share what've you done ?

There might be some changes in markdown loader to support reload #11

@bartgryszko
Copy link
Author

Long story short, what I did is basically this:

htmlLoader.call(this, markdown.render(content))

in my custom edited md-collection-loader but it emmits .json files like that:

{
  body: "Text <img src=" + require(...) + " />"
}

which is obviously not what we want as we have to "compile" the code first. It seems that Loader.exec doesn't take webpack config and loaders. The issue I have is only json file generation – I don't know yet how to emit the file correctly.

@MoOx
Copy link
Owner

MoOx commented Feb 23, 2016

You want to have a loader that will return a new url for some assets?

@bartgryszko
Copy link
Author

Exactly – but already "rendered" so we can generate json files as you do in md-collection-loader. As described here: webpack/webpack#667 – we could use exec, but it doesn't take webpack config into consideration while compiling the emitted file.

@MoOx
Copy link
Owner

MoOx commented Feb 27, 2016 via email

@thangngoc89
Copy link
Contributor

Hum. I think this is useful for me atm. But I'm not a familiar with webpack internal so I'll try to integrate this with Statinamic internal API

@thangngoc89
Copy link
Contributor

I think we should not depends on renderer but html. We can use rehype to get a HTML AST

@MoOx
Copy link
Owner

MoOx commented Sep 5, 2016

How to handle this when we will support reactdown?

@thangngoc89
Copy link
Contributor

@MoOx When we use reactdown, it should just works. Like @bgryszko said, we need to require the actually markdown file somewhere and webpack will resolve the image link for us. This mean reactdown's approach.

If we keeps our current approach, we have to parse and load those images ourself, not via webpack.

@MoOx
Copy link
Owner

MoOx commented Sep 5, 2016

Not sure to follow you. Currently markdown files are require by webpack. But this is not enough. We need to require() assets referenced in the files consumed by our loader to benefit of webpack core. Like css-loader does with url() https://github.com/webpack/css-loader/blob/5a9c1d13940194b78bff0e27284836557f962e5b/lib/loader.js#L68-L86

@thangngoc89
Copy link
Contributor

By require I mean you do it like with css files, and not with require.context and load content via json

For ex: require('./foo.md')

Those lines of code above produce this: require(../path/to/images)
When you do require('./someth.css) webpack will resolve the above require statement to actual url with file-loader (or url-loader)

@MoOx
Copy link
Owner

MoOx commented Sep 5, 2016

webpack will resolve the above require statement to actual url with file-loader (or url-loader)

yeah because of the code in css-loader above that tell webpack to use require on the content in url().

require.context is the same as require() when you call each items like here

mdContext.keys().forEach(mdContext)

But maybe I am missing something related to the fact that we return custom type (json) at the end of the loader. But I am pretty sure we can find a way (maybe my creating another loader or something like that?)

@thangngoc89
Copy link
Contributor

thangngoc89 commented Sep 5, 2016

But maybe I am missing something related to the fact that we return custom type (json) at the end of the loader.

Yes. Because we return a public path to the markdown file, so when we require it, there isn't ay require statement for webpack to resolve.

@MoOx
Copy link
Owner

MoOx commented Sep 5, 2016

Dawn, I just understood that css-loader only generate a string and that webpack will resolve require after... Well we will find a way... Will think about that after the incoming refactoring.

@thangngoc89
Copy link
Contributor

generate a string

Not a string. It generates a valid JS code with some require statement inside it.

@MoOx
Copy link
Owner

MoOx commented Sep 5, 2016

Yeah but generate code from a string ;)

@bloodyowl
Copy link
Contributor

With #925, webpack will not used to process markdown anymore. All files not handled by any plugin will be transferred in dist/assets

@MoOx
Copy link
Owner

MoOx commented Apr 20, 2017

Closed per previous comment.

@MoOx MoOx closed this as completed Apr 20, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants