I'm trying to package an application which essentially takes a screenshot webpages using puppeteer which then stores it in a folder called report. However since the number of images changes vary I am unable to define this in the asset property of pkg. How do I go about this?
I've added an image of my package.json and the actual error
*Edit:
I've tried to use
report/*.* || report/*.png
but to no avail
Related
I am working on a NetSuite instance that had custom(contractor/SuiteScript) work installed via a bundle, but it is not a third party product but made for this system. Now there are 2 listings in the dropdown for each file. In other words, if I am adding a file as a library, it shows up twice and I don't know which reference is the correct one to choose. I used search to find the duplicate file name is in the bundle install. Can I safely remove or delete the bundle? thanks any help is appreciated.
You cannot typically remove individual files from a bundle. If you do not need the functionality of the bundle anymore than you can remove it at your discretion by going to Customization>SuiteBundler>Search & Install Bundles>List, then under the action icon click 'Uninstall'.
I wouldn't try to delete a script library from a bundle folder. Even if you are uploading an identical library there may be references in the bundle scripts to the original library that will be broken when if you delete it.
If you are wondering which one you are selecting from the drop down one thing you could do is figure out the internal id of your library file then run a search on your script file that pulls in the library file id's and make sure that they match.
I'm currently creating an npm package that will consist of a series of React components that are common to some applications I am maintaining.
My intention is to be able to import this components individually as needed, not all at once. So for instance if I have the components Accordion, DropDown and Widget, but I'm only using one of them, I'd like for only its code to be required.
My understanding is that I would need to be able to do something like
import Widget from 'components/Widget';
Instead of
import {Widget} from 'components';
But I can't get the first version to work. I have not published this package, so I'm using npm link to test it on another application. I'm not even sure what to Google to solve the problem myself, so I'd also appreciate links to relevant documentation on this matter.
Thanks.
So, of course a few minutes after asking my question I resolved the issue:
First, as Yacine Filali commented on my question above, I need to have individual files in order for this to work (this part I had already figured out).
However, I was incorrectly assuming that the root of my package was going to be set to whichever directory my entry file was in. So in package.json I had set
"main": "./lib/index.js"
Incorrectly assuming that the folder structure would be read from there. After altering my configuration to build everything into the root directory it worked perfectly.
(Of course, I'm now working on a better alternative, like generating a package.json for the lib folder)
In your component:
export default Widget
In your index:
export { default as Component } from './Component'
I'm currently working on a project that requires me to display a folder full of files form the inside of a server. I'm using the serve-index npm module to do so (https://www.npmjs.com/package/serve-index).
My issue is that the file names I'm using are too long. Serve-index displays 3 columns at a time so it's hard to read the entire file name at a glance. Is there a way to display either 1 or 2 columns?
Like Molda said, it was all css based. All I need was to specify a custom css file in express like the following.
app.use('/text_files', serveIndex(__dirname + '/text_files', {'stylesheet':'./styles/directories.css'}));
Using Gulp and Node.js, I'm creating a proof of concept that generates sprites from folders of images, then versions the generated sprites so they have unique file names for cache busting purposes.
I'm using https://www.npmjs.com/package/gulp-rev to version the sprites (this works!), but I'm having trouble updating CSS files with references to the images. There are some tools that I have looked at for this purpose but I haven't been able to get them to work. The two that I have look at are:
https://github.com/jamesknelson/gulp-rev-replace
(Seems fully featured by can't figure it out)
and..
https://github.com/galkinrost/gulp-rev-css-url
(Got working but couldn't separate the destination for the revisioned images files and the updated CSS with the new images names)
Essentially I want to grab all the images from gulp-image-versioning-poc/images/sprites/*.png and then version them, put the resulting images in gulp-image-versioning-poc/dist/ and update the references to those images in gulp-image-versioning-poc/css/*.css
I've created a simplified example of what I currently have here:
https://github.com/olthof/gulp-image-versioning-poc
If anyone could help me tackling this problem I would be very grateful!!!
I'm using the Node.js version of TiddlyWiki, and I'd like to link to images on my filesystem.
The documentation listed here doesn't work; in the [img[path]] tag, for the path part I put something like /Users/documents/ken/path_to_image.jpg yet nothing shows up in the tiddler.
My wiki exists in /Users/documents/ken/wiki.
I know this is an old post, but zacts stated that you can use a macro plugin or simply use the [img] tag to point to the relative path of the image from the tiddlywiki.html file, but the op is using the node.js version, and zacts apparently didn't read that. There is no tiddlywiki.html file for TiddlyWiki on node.js. That only works with the static .html version of tiddlywiki, not the node.js version.
Currently there is no way to point to a local file through the node.js version of Tiddlywiki as node.js is not a webserver, therefore it does not see subfolders like /images/ off of the root url. The only way is to run a parallel web server on the same machine and use the full web url to the images served up from the web server.
In case someone else stumbles across this problem:
I could not find this documented anywhere, but what seems to work is to just copy the image in the tiddlers directory, then restart the nodejs server, and search for the image title from tiddlywiki. There will be a tiddler that contains that image, that you can edit at your leisure.
Alternatively, copy the image as image_name.png (or image_name.jpg) into the tiddlers directory, and create a image_name.png.meta text file with the following contents:
title: image_name
type: image/jpeg
Upon restart of the tiddlywiki nodejs server, a tiddler with title image_name which contains the image will be there.
If you are using the Node.js version, you can simply put it in the ./files folder, and then use [img[. /files/xxx.jpg]] to reference it.
I had this same issue recently, and I found a neat little solution for it. Let me send you the links, and I'll post the snippets here.
I happened to stumble across this tiddlywiki image gallery homepage that linked to a macro plugin that lets you link in local images. Here is the link to the tiddler for the plugin: http://www.richshumaker.com/tw5/tw-photo.html#External%20Image%20Path. Here is the original TiddlyWiki google groups post of the plugin for this: https://groups.google.com/forum/#!msg/tiddlywiki/ChRV6sjQpn4/bCm35_XhGmkJ.
I hope this helps! =) (note: when I get more time I may clean up the formatting of this post).
It is very simple, you use _canonical_uri field
_canonical_uri field
The field value is something like "./wiki/path_to_image.jpg" (mine is "./files") in the same level as the tiddlers folder. I did not experimented with files outside the root folder of the wiki. The dot in the path might be ommited.
The content type might be "audio/mp3" "image/jpg" look at the "parser" shadow tiddlers. Your Browser might support more content types like "audio/wav" but you would have to add this line to "$:/core/modules/parsers/audioparser.js" For example. Might be the same thing for images. Check your browser support.
I really do not know why this fact is so obscure, but it work wonders.