Imagine you want to produce a specific static asset for your Next.js web app. An image collage for example, or perhaps a web manifest or site map.
My current strategy for this kind of scenario is to make a script that can produce the desired output directly in my /public folder, but then I have to push the built file along with my source files in my repo, which is less than ideal.
Or, I have to set up a separate parallel asset pipeline to re-create the asset when the source files change and which I would launch whenever I launch next dev. I would also need to run the script when next build is called.
In either case, I then also need to ignore the built file so it's not pushed along with the other files in /public…
This kind of solution feels like I'm reinventing the wheel and losing the zero-config ideal around which the Next.js ecosystem revolves.
I'd much rather provide Next.js with my custom script and just hook into the existing asset pipeline, dev server lifecycle, and build script, letting Next.js do the heavy lifting for me, hence my question:
Does Next.js have a plugin architecture, extensions, or perhaps lifecycle hooks I could tap into to implement a custom asset pipeline?
I see some pluggable loaders exist for Next.js, such as the MDX loader, but it's not clear to me whether this is the way to go for what I'm trying to do, and I'm not finding any documentation about how to write my own loader, so I'm afraid this might not be a recommended approach…
Related
We are creating a microservice bootstrap project with a code-generator using a Backstage application directory - allowing users to create a starter microservice project using the backstage app wizard.
This means we have some java application code that was then templatized using nunjucks.
However, if other developers want to modify or evolve that template code, they would have to render the template to java code (a spring boot app) then develop on it: modify, test, debug. And then when they are done, they would have to re-templatize the code before committing the template code back to backstage.
My question is how can we automate or simplify that re-templatizing step back to nunjucks. Maybe we can preserve some of the templating info in comments so that we can automatically re-apply templating to those areas? Is there another simpler way to automate or assist turning the code back into a template?
Since multiple developers will be working on this over a long period of time, I think it would be unrealistic to expect users to update back template expressions everywhere if they become interspersed throughout the code.
I am using this code: https://github.com/pradeepramakrishna/Lightning-Experience/tree/master/aura-components to compile on my org.
I have got one components as eventLib.lib and interactive.js in eventLib folder. I have put this folder in c:MyDevOrg\force-app\main\default\aura folder in the local machine and tried to deploy in the org using VSCode but it didn't work.
I tried creating folder in the Files tab and added the interactive.js in the folder but that is also not seeming to work with the Aura components.
How can I deploy this lib into the org as it is being used in some Aura components.
We don't know what you're trying to achieve. You asked a very technical question to which the answer is "you're probably doing it wrong". Instead try to write what business functionality you are trying to achieve and you might get better answers.
You shouldn't have to import ui:eventLib. It's supposed to be part of core Salesforce's Aura components framework. But.
You've referenced a repo that wasn't updated in a while, no promises this still compiles / is best way to do X.
This repo seems to rely on open source Aura framework which is well... dead in the water.
You might be able to reuse something from this repo in your app using SF's built-in tags - but whole ui: library has been deprecated. Announced in Winter'20 = almost 2 years ago, finally dead in May 2021.
I don't think eventLib was ever exposed, might be something needed just in open source version which complicates the matter more. The answer would be to not work with the really "decompiled" tags but with their higher abstracted versions like ui:inputDate.
So, back to my question. What exactly are you trying to achieve.
You want to build something on pure SF platform (use pure Aura/LWC).
Want to have an app written in Angular, React etc, pure JS, connecting to SF data via API? (build it, upload as static resourcethen import using lightning:container)
want to prettify an existing Java/PHP/.NET app, make it look more Lightning-ish and embed it as iframe? (look into https://www.lightningdesignsystem.com/ and connected apps + "canvas")
want to expose piece of SF as reusable element that can be embedded in another website but could even be an Outlook plugin? (search for "lightning out")
want to look at modern equivalent of that old open source Aura repo and decide what to do next? Check https://lwc.dev/ out.
Upon creating a UI target to the app two files will be created in Xcode.
MyAppUITests.swift and info.plist
These both files are placed under the MyAppUITests folder.
The swift class has some default test methods to starts with whereas the plist has the settings info of the created UI test. We are then write test cases, write some utility classes etc. The utility classes also saved under the UI test target. The whole setup works fine with "MyApp".
Requirement: I want to give this setup to some other tester/developer who is a newbie. Means, if they want to implement the UI testing in their app, I want to give them a sample setup which will contain the UI test target with some sample test cases and utility methods.
Current flow: Currently we are having documents regarding the UI test setup, the usage of the written utilities, etc. A person can read those documents and do all the steps manually to setup the UI test environment.
We want to take it to the next level by automate this setup process. Something like, if I keep the sample files in a repo and create a run script that can import the files from repo and add it to the newbie's source code while running. I'm not sure this is possible and I appreciate the suggestions on it.
You should probably do the generic preparation by yourself. Then, with the help of git write a bash script that does this preparation. I suppose you can automate some of the most difficult to automate steps with xcodeproj generators like
https://github.com/yonaskolb/XcodeGen
I'm using modernizr in my ASP.net MVC application, and I'd like to use the inputformaction detect added in Modernizr v3. The latest version available on nuget is 2.8.3. So that means I need to add it independently from nuget. There doesn't seem to be any official full build.
The only thing I can find on their website is Download, which prompts me to create a custom build. If I select the features I'm using now, then I'll need to come back to this website every time I want a new detect, and remember all the options I chose last time. That's not really practical. I've also found that you can make custom builds using a node package and a .json definition file. I don't really feel like installing node just for this if I can avoid it.
All I want is a complete build of modernizr. Is there any way to do it other than writing a script to check all the checkboxes on their download page?
There is no such thing as a "complete" build of Modernizr. While it may be a minor inconvenience for you to rebuild when you need new detects, it can cost your users tons of time and money downloading and running javascript that is completely unneeded. There are a bunch of tools that will automate the custom build for you (bower, npm, grunt-modernizr, gulp-modernizr).
If you want a build that contains all of the options - which again is huge and horrible on perf, you can use https://modernizr.com/download?do_not_use_in_production
I'm developing a web app.
If I include a jQuery plugin (or the jQuery file itself), this has to be put under my static directory, which is under SCM, to be served correctly.
Should I gitignore it, or add it, even if I don't plan on modifying anything from it?
And what about binary files (graphic resources) that might come with it?
Thanks in advance for any advice!
My view is that everything you need for your application to run correctly needs to be managed. This includes third-party code.
If you don't put it under SCM, how is it going to get deployed correctly on your production systems? If you have other ways of ensuring that, that's fine, but otherwise you run the risk that successful deployment is a matter of people remembering to do all the right things, rather than some automated low-risk "push the button" procedure.
If you don't manage it under SCM or something similar, how do you ensure that the versions you develop against and test against are the same? And that they're the same as production? Debugging an issue caused by a version difference you don't notice can be horrible.
I generally add external resources to my project directly. Doing so facilitates deployment and ensures that if someone changes the version of this file in your project, you have a clear audit history of what happened in case it causes issues in the code that you've written. Developers should know not to modify these external resources.
You could use something like git submodules, I suppose, but I haven't felt that this is worth the hassle in the past.
Binary files from external sources can be checked in to the project as well, although if they're extremely large you may want to consider a different approach.
There aren't a lot of reasons not to put external resources like jQuery into your repo:
If you pull it down from jQuery every time you check out or deploy, you have less control over which version you're using. This holds true for most third-party libraries; you probably don't want to upgrade your libraries without testing with your code to see if it breaks something.
You'll always have a complete copy of your site when you check out your repository and you won't need to go seeking resources that may have become unavailable.
For small (in terms of filesize) things like jQuery and images, I'd just add them unless you're really, really concerned about space.
It depends.
These arguments relate to having a copy of the library on your system and not pulling it from it's original location.
Arguments in favour:
It will ensure that everything needed for your project can be found in one place when someone else joins your development team. I've lost count of the number of times I've had to scramble around looking for the right versions of libraries in order to be able to get something working.
If you make any modifications to the library you can make these changes to the source controlled version so when a new version comes out you use the source control's merging tools to ensure your edits don't go missing.
Arguments against:
It could mean everyone has a copy of the library locally - unless you map the 3rd party tools to a central server.
Deploying could be problematical - again unless you map the 3rd party tools to a central server and don't include them in the deploy script.