thierryc
commented
6 years ago Use URL to import your images.
like
source={`http://127.0.0.1:8080/Lists/list-items/Icons/${cat}@2x.png`}PS is ready for sketch 48.
"react-sketchapp": "^1.0.0",Closed dlehmhus closed 4 years ago
thierryc
commented
6 years ago Use URL to import your images.
like
source={`http://127.0.0.1:8080/Lists/list-items/Icons/${cat}@2x.png`}PS is ready for sketch 48.
"react-sketchapp": "^1.0.0",
LincMitch
commented
6 years ago How about if your rendering to SketchApp and not rendering to Web?
LincMitch
commented
6 years ago I also get a crash when trying to use:
<Image source={require('./image.png')} />
Sketch 48.1 and v1.0.0
But if I remove require('...') and just use <Image source={'./image.png'} /> it doesn't crash. Instead I get an empty red box in place of the image dimensions .
In fact I'm not sure what require('...') is used for as copied the code.
thierryc
commented
6 years ago Use a server. http://
Good Node server. https://www.npmjs.com/package/http-server
dlehmhus
commented
6 years ago @thierryc you're right, it works via URL imports! In my case, I would prefer to import my assets directly into my components, because I have a rather complex workspace setup ( by my standards 😄 ) sharing components between a web-, native- and a sketch-project.
thierryc
commented
6 years ago Via a Base64 image ? How do you import your image in js ? via babel ?
https://www.npmjs.com/package/babel-plugin-nodejs-import-images
LincMitch
commented
6 years ago Local images used to work in 1.0.0-beta.5.
thierryc
commented
6 years ago I read the source of the render and for me extractURLFromSource expect a URI string.
const image = makeImageDataFromUrl(extractURLFromSource(props.source)); extractURLFromSource()
Try file:// ?
LincMitch
commented
6 years ago Noticed this closed issue which point to SKPM #199
LincMitch
commented
6 years ago file:// didn't appear to work. So am using a localhost for now, until local images become available again.
csantiago132
commented
6 years ago @LincMitch my work-around is to upload assets to repo and import jpg|png|gif|svg| via direct URL. works like a charm too
LincMitch
commented
6 years ago Sounds good @csantiago132 can you send a code example?
csantiago132
commented
6 years ago @LincMitch ill set one up and send it tomorrow
LincMitch
commented
6 years ago Thx @csantiago132 looking forward to it
mathieudutour
commented
6 years ago no issue for me with
<Image source={require('./img.png')} style={{
height: 220,
width: 200,
resizeMode: 'contain',
marginBottom: 20,
borderRadius: 10,
}} />sketch 48, react-sketchapp 1.0, @skpm/builder 0.2.10
What the crash logs?
csantiago132
commented
6 years ago @mathieudutour i tried this and used to fail, ill update my project and let you know. @LincMitch I basically do what its on the Profile Cards example (i have a mess on mine as were working on it, Ill make some time today to create one thats not related to what we're working).
But if it helps, TL; DR version of it: I provide a URL on the JSON, then
<Image src={this.props.img} .../>Hope this helps while I setup an example for you. This way i can reuse the component and loop thu diff data-sets and use it cross diff screens
LincMitch
commented
6 years ago @mathieudutour do you mean the message from the sketch report dialog box? If so its rather long.
LincMitch
commented
6 years ago @mathieudutour BTY your example still crashes Sketchapp
mathieudutour
commented
6 years ago well we need something to debug, it's working for me, I just tested this morning so if you can't provide a reliable way to reproduce, we won't get far...
LincMitch
commented
6 years ago There is no terminal error just the crash report that sketch wants me to send to them. Again, its very long, so hope it's what you wanted.
mathieudutour
commented
6 years ago hum it doesn't even look like it's calling the plugin 🤔
Do you have a repo with a repro?
LincMitch
commented
6 years ago @mathieudutour I don't have a git hub repo, just installed locally. Do you need me to set one up?
dlehmhus
commented
6 years ago @mathieudutour here is an example-repo that causes my sketch app to crash the same way as @LincMitch describes!
mathieudutour
commented
6 years ago 
works fine for me :(
dlehmhus
commented
6 years ago Okay, that is odd. I just asked a coworker to run my repo and he is having the same problem. It seems like I'm missing something existentiell... hmm..
LincMitch
commented
6 years ago @dlehmhus what macOS you running? Mines Sierra 10.12.6. Not sure if that would cause an issue like this, just thought it worth a mention.
dlehmhus
commented
6 years ago Right now my setup is:
dmeehan1968
commented
6 years ago This still appears to be happening on 48.2 using @dlehmhus example repo, and on my own code. Any update?
I've tried using an http:// url from a public server but all I get is a view of the desired dimensions which is filled in red. I don't see how a local server improves on that.
silviopaganini
commented
6 years ago same here.. crashing on 48.2 any updates?
dmeehan1968
commented
6 years ago I've been able to isolate this from any code, building a minimal sketch plugin that contains a require() for an asset (image or text) and that causes Sketch to crash if you use skpm-build with the --run flag. As a workaround, you can build without running (with --watch if required) and then use the Sketch > Plugins > MyPlugin menu to run the plugin manually, and it will work.
jhampton
commented
6 years ago FWIW - Confirmed on OS X Sierra 10.12.6, Sketch 48.2, and latest sketchapp (from yesterday). I also logged-out the skpm path that's being generated from the resourceLoader:
Transforming incoming path [../Resources/_webpack_resources/6b51d3460464a7505a248809d1b1b2ed.png]
New outgoing path ["file://" + context.plugin.urlForResourceNamed("_webpack_resources/6b51d3460464a7505a248809d1b1b2ed.png").path()]
Transforming incoming path [../Resources/_webpack_resources/866b178fd9de26e5744aff4857d05deb.png]
New outgoing path ["file://" + context.plugin.urlForResourceNamed("_webpack_resources/866b178fd9de26e5744aff4857d05deb.png").path()]So the assets are getting copied into the plugin, and the path that's being translated by skpm are correct. I also checked the copied assets, and they render just fine, so it doesn't appear to be a corruption issue.
As a testing step with my own minimal codebase, I pulled latest on skpm to make sure it's not a lagging dependency, same result. A search for related issues on the skpm repo doesn't provide any good hits on this problem being confirmed or fixed.
Confirmed same behavior with the repo @dlehmhus provided. But it only crashes when using npm run render, which means that skpm's --watch behavior may be the culprit. The version of skpm has some outdated deps. I get this warning when using npm run render
(node:79496) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see https://github.com/webpack/loader-utils/issues/56
parseQuery() will be replaced with getOptions() in the next major version of loader-utils.It may be that webpack's hot reloading is the issue here. I'll investigate and report back if I make any progress.
dmeehan1968
commented
6 years ago @mathieudutour Ok, I've now isolated the problem, but can't find a workaround.
The trigger for the crash is the line generated by the resourceLoader:
module.exports = "file://" + context.plugin.urlForResourceNamed("_webpack_resources/754269c360d531468abfcc3b7be4e6bb.png").path();Specifically, the context.plugin.urlForResourceNamed() call appears to return an unstable object (possibly deallocated memory). I've been able to log it without crashing, but I can't return it via module.exports nor can I copy any of it.
Also, the path() call is redundant, because the URL is already prefixed by file://, but this is not the trigger for the crash in itself, just an observation.
I can't find any further documentation or source for the plugin object, other than its headers. That seems to suggest that the return value is an object ID, and therefore I think is at risk of being garbage collected without appropriate tracking (if my memory of Objective-C serves me correctly).
I can't conceive of another way of getting the absolute path to the resource, without making something brittle, so this appears to be a fault in Sketch that needs resolving to make progress.
To determine the above I used sketchtool to manually run the plugin after build, and this still crashes Sketch, so I think that at least proves that the problem is not related to the way that webpack triggers the plugin run after bundling is complete.
Just to be clear, it is possible to run the plugin manually from the Sketch plugin menu after building, so the context for where the plugin function is broken is specific to when the plugin is run via the CLI.
I tried switching the skpm/builder to use the older (v43) command interface but this threw an exception, so probably is no longer supported in v48.2.
I've created a test repo here - https://github.com/dmeehan1968/sketch-require-crash
dmeehan1968
commented
6 years ago @jhampton Thanks for the input, see my comment above, I isolated webpack and its not related to anything its doing, nor is it a --watch related issue.
mathieudutour
commented
6 years ago Specifically, the context.plugin.urlForResourceNamed() call appears to return an unstable object (possibly deallocated memory). I've been able to log it without crashing, but I can't return it via module.exports nor can I copy any of it.
That seems like an issue in Sketch, we might not set the context.plugin when running with sketchtool. I'll file and see if I can fix it for Sketch 50
Also, the path() call is redundant, because the URL is already prefixed by file://, but this is not the trigger for the crash in itself, just an observation.
I don't think so, context.plugin.urlForResourceNamed returns a NSURL and we want a string, hence the .path()
dmeehan1968
commented
6 years ago context.plugin.urlForResourceNamed returns a NSURL and we want a string, hence the .path()
I was going by what I could see when I used log(). Perhaps [NSURL absoluteString]?
Here is what context holds.
{
api = "<MOJavaScriptObject: 0x60c000c22340>";
command = "<MSPluginCommand: 0x6000004ee580>";
document = "<MSDocument: 0x7fa85791b370>";
plugin = "<MSPluginBundle: 0x6080004f6a80>";
scriptPath = "/Users/dmeehan/Documents/Dropbox/Projects/node-tutorials/skpm-require-crash/plugin.sketchplugin/Contents/Sketch/my-command.js";
scriptURL = "file:///Users/dmeehan/Documents/Dropbox/Projects/node-tutorials/skpm-require-crash/plugin.sketchplugin/Contents/Sketch/my-command.js";
selection = (
);
}And that got me to writing an dirty, ugly hack 😁
const parts = context
.scriptPath
.split('/')
const index = parts
.slice(0)
.reverse()
.findIndex(part => /.sketchplugin$/i.test(part))
const root = parts.slice(0, -index).concat(['Contents', 'Resources']).join('/')
module.exports = 'file://' + root + '/' + "_webpack_resources/754269c360d531468abfcc3b7be4e6bb.png";And that works. I then decided to save myself the prefixing with the 'file://' literal by using the context.scriptURL value. And hey-ho, it crashed.
I don't know what that means. I think it means Sketch might have a bit of an issue with NSURL, but only when plugins are run in this context.
I'm not suggesting you'd use the above hack in place of the existing resource loader, but it gave some further insight.
mathieudutour
commented
6 years ago context.scriptURL is a NSURL so you need to use scriptURL.path() or something. You can't just concatenate it with a string
dmeehan1968
commented
6 years ago Is this stuff actually documented somewhere?
dmeehan1968
commented
6 years ago So, I think that proves that the way Sketch exposes NSURL instances is problematic when the plugin is invoked from sketchtool. You seemingly can't convert the NSURL instance to a string, via path() or absoluteString() without it leading to a crash. Whereas the context.scriptPath is already a string, and is handled ok.
From the logging I've tried, the crash is NOT on the access of the NSURL, but sometime a fraction of a second later. In my test repo, the only thing that doesn't show up is:
context.document.showMessage("It's alive 🙌")But its possible it gets that far but the window disappears before its possible to notice.
nixvalentine
commented
6 years ago any updates on this bug so far? I see it closed but I could not see any solution provided here yet, or I'm just too ignorant on this,(if so, could any kindly enough to show me the answer?). Sorry I'm a designer learning to code.
csantiago132
commented
6 years ago @nixvalentine a workaround is to pass urls instead of paths to the images, at least that’s what I’m doing
thierryc
commented
6 years ago @nixvalentine
2 Simple solutions for designers (like me)
<Image
source={require('./img.png')}
style={{
height: 220,
width: 200,
resizeMode: 'contain',
marginBottom: 20,
borderRadius: 10,
}} />If your assets are recently changed. Kill your watch process and relaunch it or rebuild your plug-in.
<Image
source={`http://127.0.0.1:8080/Lists/list-items/Icons/${cat}@2x.png`}
style={{
height: 220,
width: 200,
resizeMode: 'contain',
marginBottom: 20,
borderRadius: 10,
}} />You need to have an HTTP server.
context.scriptURL is a NSURL so you need to use scriptURL.path() or something. You can't just concatenate it with a string
That seems like an issue in Sketch, we might not set the context.plugin when running with sketchtool. I'll file and see if I can fix it for Sketch 50
csantiago132
commented
6 years ago @thierryc idk if it owuld help you but I am hosting the images from the repo itself to avoid other people having issues with assets but glad to see this workaround, didnt think of it (serving them local)
👋 Hello! Thanks for contributing. Please use the template that matches your intention
I am... Dario Lehmhus
Expected behavior: Import image asset into Component
Observed behavior: Sketch quits unexpectedly
How to reproduce:
import logo from 'path/to/asset/logo.png';Sketch version: 47.1
Dependencies: