window.pipedriveLeadboosterConfig = { basis: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', versie: 2, } ;(functie () { var w = venster als (w.LeadBooster) { console.warn('LeadBooster bestaat al') } anders { w.LeadBooster = { q: [], on: functie (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: functie (n) { this.q.push({ t: 't', n: n }) }, } } })() Eerste hulp bij kapotte JavaScript afhankelijkheden - The Codest
The Codest
  • Over ons
  • Diensten
    • Software Ontwikkeling
      • Frontend ontwikkeling
      • Backend ontwikkeling
    • Staff Augmentation
      • Frontend ontwikkelaars
      • Backend ontwikkelaars
      • Gegevensingenieurs
      • Cloud Ingenieurs
      • QA ingenieurs
      • Andere
    • Het advies
      • Audit & Consulting
  • Industrie
    • Fintech & Bankieren
    • E-commerce
    • Adtech
    • Gezondheidstechnologie
    • Productie
    • Logistiek
    • Automotive
    • IOT
  • Waarde voor
    • CEO
    • CTO
    • Leveringsmanager
  • Ons team
  • Case Studies
  • Weten hoe
    • Blog
    • Ontmoetingen
    • Webinars
    • Bronnen
Carrière Neem contact op
  • Over ons
  • Diensten
    • Software Ontwikkeling
      • Frontend ontwikkeling
      • Backend ontwikkeling
    • Staff Augmentation
      • Frontend ontwikkelaars
      • Backend ontwikkelaars
      • Gegevensingenieurs
      • Cloud Ingenieurs
      • QA ingenieurs
      • Andere
    • Het advies
      • Audit & Consulting
  • Waarde voor
    • CEO
    • CTO
    • Leveringsmanager
  • Ons team
  • Case Studies
  • Weten hoe
    • Blog
    • Ontmoetingen
    • Webinars
    • Bronnen
Carrière Neem contact op
Pijl terug KEREN TERUG
2018-12-27
Software Ontwikkeling

Eerste hulp bij kapotte JavaScript afhankelijkheden

Daniel Grek

Als je softwareontwikkelaar bent, dan weet je waarschijnlijk al dat een van je vele rollen beslist niet de zoveelste wieluitvinder is. Tenminste, niet in de meeste gevallen.

Ik wil graag schrijven over JavaScript afhankelijkheden. Maar laten we bij het begin beginnen. Als je softwareontwikkelaar bent, dan weet je waarschijnlijk al dat een van je vele rollen beslist niet de zoveelste wieluitvinder is. Tenminste, niet in de meeste gevallen. De wereld is ver genoeg gevorderd om te zeggen dat er tegenwoordig pakketten bestaan voor bijna alles, wat onze ontwikkeling gemakkelijker en efficiënter maakt.

Dit is natuurlijk geen aanmoediging om je interesse in andere zaken te verliezen - elk pakket heeft een vrij grote ruimte om te verbeteren en te evolueren. Je bedrijfsdoel is echter om een compleet product op een bord precies op tijd of zelfs voordat het op is. Pakketten helpen je om die plannen uit te voeren en brengen npm of garen bovenaan het lijstje van je beste vrienden, maar let op: elke oplossing, ook deze, kan ook risico's met zich meebrengen. En we zullen proberen het te beschrijven en je een betere manier laten zien om ermee weg te komen in het onderstaande artikel.

Laten we beginnen met een verhaal...

Stel je een grote JavaScript voor project. Zakelijke vereisten verplichten ontwikkelaars om een specifiek pakket te gebruiken dat een goede integratie met een ander systeem van een klant mogelijk maakt. En dat is helemaal prima. MVP op tijd is gebracht, het volgende contract is getekend en de ontwikkeling gaat door.. De klant vraagt om het volgende deel van een systeem te integreren, waarvoor uw pakketupdate nodig is.

Dit deel gaat goed, totdat de tests worden uitgevoerd. Het lijkt erop dat het pakket een eenvoudige, maar onhandige bug bevat, die nog in geen enkele productrelease is opgelost en het is bekend dat dit niet snel genoeg zal gebeuren. Je kunt je knooppuntmodules map - zou het uit je repository verwijderd moeten worden van tracking, daarom zullen je medewerkers nooit iets weten van je wijzigingen! Nou, terwijl je dit las, heb je waarschijnlijk al begrepen wat je moet doen - fork. Maar heb je echt zo'n hamer nodig?

Uw probleem begrijpen

Je moet je ervan bewust zijn of het probleem waar je mee te maken hebt alleen betrekking heeft op jou of op een grotere gemeenschap. Soms interpreteren mensen het ontbreken van bepaalde functionaliteit als een bug, wat niet altijd correct is. Daarom, jouw oplossing wordt mogelijk niet geaccepteerd door een community en niet opgenomen in een officieel archief. Maar je hebt het nog steeds hier en nu nodig. Nou, laten we het oplappen!

Volgens de release notes van de github repository, patch-pakket ) werd officieel uitgebracht in mei 2017. It is een krachtig hulpprogramma waarmee wijzigingen binnen een afhankelijkheidsproject kunnen worden geïnstalleerd in je knooppuntmodules map. Sommigen zullen zeggen dat dit nogal gek is - door het installatiecommando te vuren zal je afhankelijkheidsbeheerder de wijzigingen overschrijven.

Nou, dit is correct. Een patchpakket bestaat echter naast npm en garen perfect (ik moet toegeven dat het tot nu toe iets beter werkt met npm, je kunt meer lezen in "Waarom je postinstall-prepare zou moeten gebruiken met Yarn?" sectie van het README-bestand) en maakt optimaal gebruik van een scriptvoorbereiding ("script": {"prepare":""}) van je pakket.json bestand. Patch-pakket maakt letterlijk een diff map aan tussen jouw wijzigingen en het originele pakket, opgeslagen in de patch map van je eigenlijke project..

Na het uitvoeren van het installatiecommando en het downloaden van alle afhankelijkheden, past het dat verschil toe op de projectmap en maakt het een perfecte reconstructie van je wijzigingen voor alle medewerkers. Het maakt je leven eenvoudiger, nietwaar? De oplossing heeft ook enkele nadelen. Het patchpakket kan geen afhankelijkheden van je pakket repareren of wijzigingen aanbrengen in pakket.json.

In dit geval kunt u de fork-oplossing gebruiken. Je moet ook rekening houden met het aantal wijzigingen dat je gaat toepassen in je afhankelijkheidspakket en of ze in de loop van de tijd zullen groeien. In het geval van wel - moet je goed nadenken bij het gebruik van fork, aangezien dit een project van jezelf is.

Wees niet egoïstisch!

Patchen is een geweldige manier om je afhankelijkheden te repareren zonder eindeloze forks aan te maken en meerdere projectbronnen te genereren. Maar je moet altijd onthouden dat het profiteren van de gemeenschap geen eenrichtingsverkeer moet zijn. Als je een bug vindt of het gevoel hebt dat je het pakket dat je gebruikt kunt verbeteren, moet je altijd overwegen om anderen te helpen door een probleem te registreren of zelfs door bij te dragen aan het project!

Verwante artikelen

Software Ontwikkeling

Bouw Toekomstbestendige Web Apps: Inzichten van The Codest's Expert Team

Ontdek hoe The Codest uitblinkt in het creëren van schaalbare, interactieve webapplicaties met geavanceerde technologieën, het leveren van naadloze gebruikerservaringen op alle platforms. Ontdek hoe onze expertise digitale transformatie en business...

DE BESTE
Software Ontwikkeling

Top 10 in Letland gevestigde bedrijven voor softwareontwikkeling

Lees meer over de beste softwareontwikkelingsbedrijven van Letland en hun innovatieve oplossingen in ons nieuwste artikel. Ontdek hoe deze technologieleiders uw bedrijf kunnen helpen verbeteren.

thecodest
Oplossingen voor ondernemingen en schaalvergroting

Essentiële Java-softwareontwikkeling: Een gids voor succesvol uitbesteden

Verken deze essentiële gids over succesvolle outsourcing Java-softwareontwikkeling om de efficiëntie te verbeteren, toegang te krijgen tot expertise en projectsucces te stimuleren met The Codest.

thecodest
Software Ontwikkeling

De ultieme gids voor outsourcing in Polen

De sterke groei van outsourcing in Polen wordt gedreven door economische, educatieve en technologische vooruitgang, die IT-groei en een bedrijfsvriendelijk klimaat stimuleert.

DeCodest
Oplossingen voor ondernemingen en schaalvergroting

De complete gids voor IT-auditmiddelen en -technieken

IT-audits zorgen voor veilige, efficiënte en compliant systemen. Lees het volledige artikel om meer te weten te komen over het belang ervan.

The Codest
Jakub Jakubowicz CTO & medeoprichter

Abonneer je op onze kennisbank en blijf op de hoogte van de expertise uit de IT-sector.

    Over ons

    The Codest - Internationaal softwareontwikkelingsbedrijf met technische hubs in Polen.

    Verenigd Koninkrijk - Hoofdkantoor

    • Kantoor 303B, 182-184 High Street North E6 2JA
      Londen, Engeland

    Polen - Lokale technologieknooppunten

    • Fabryczna kantorenpark, Aleja
      Pokoju 18, 31-564 Krakau
    • Hersenambassade, Konstruktorska
      11, 02-673 Warschau, Polen

      The Codest

    • Home
    • Over ons
    • Diensten
    • Case Studies
    • Weten hoe
    • Carrière
    • Woordenboek

      Diensten

    • Het advies
    • Software Ontwikkeling
    • Backend ontwikkeling
    • Frontend ontwikkeling
    • Staff Augmentation
    • Backend ontwikkelaars
    • Cloud Ingenieurs
    • Gegevensingenieurs
    • Andere
    • QA ingenieurs

      Bronnen

    • Feiten en fabels over samenwerken met een externe partner voor softwareontwikkeling
    • Van de VS naar Europa: Waarom Amerikaanse startups besluiten naar Europa te verhuizen
    • Tech Offshore Ontwikkelingshubs Vergelijking: Tech Offshore Europa (Polen), ASEAN (Filippijnen), Eurazië (Turkije)
    • Wat zijn de grootste uitdagingen voor CTO's en CIO's?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Gebruiksvoorwaarden website

    Copyright © 2025 door The Codest. Alle rechten voorbehouden.

    nl_NLDutch
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish etEstonian elGreek nl_NLDutch